[libvirt] [v7 00/10] Support cache tune in libvirt

[Eli Qiao]

--  
Best regards  
Eli

天涯无处不重逢
a leaf duckweed belongs to the sea, where not to meet in life  

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Monday, 20 February 2017 at 3:59 PM, Martin Kletzander wrote:

> On Sun, Feb 19, 2017 at 12:20:55PM -0300, Marcelo Tosatti wrote:
> > On Sun, Feb 19, 2017 at 12:01:57PM -0300, Marcelo Tosatti wrote:
> > >  
> > > How does the management software query the amount of allocatable cache
> > > again?
> > >  
> > > Section from another discussion:
> > >  
> > > > The second case is necessary to get updated free space information.
> > >  
> > > Just VM initialization time could be enough as virConnectGetCapabilities
> > > would just know the total and free size would be reported in an API (if
> > > I rememer the discussion correctly)
> > >  
> > > Martin
> >  
> > Yes, i think this is missing because the interface was designed
> > with only libvirt in mind: the "reserved" field returns the amount of
> > cache reserved only by VMs.
> >  
> > So if there is another application on the same L3 socket
> > with a cache reservation, "reserved" fails to report it.
> >  
> > Eli can you expose the amount of free allocatable cache space
> > (where non-free includes space used by other reservations) in a
> > 'free_space' field in the cache output of virConnectGetCapabilities?
> >  
>  
>  
> There should be an API for that instead. Capabilities are supposed to
> show what the hardware is capable of, not what the actual state is.
>  
> If my opinion is not enough, see here:
>  
> https://www.redhat.com/archives/libvir-list/2017-January/msg00500.html

Sure, thanks Martin point the link , the plan is to provide API to query cache left.   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170220/3342ac2b/attachment-0001.htm>