[libvirt] [v4 0/9] Support cache tune in libvirt

[Eli Qiao]

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


On Wednesday, 15 February 2017 at 1:14 AM, Marcelo Tosatti wrote:

> On Tue, Feb 14, 2017 at 09:37:02AM +0100, Martin Kletzander wrote:
> > On Mon, Feb 13, 2017 at 04:09:13PM -0200, Marcelo Tosatti wrote:
> > > On Mon, Feb 13, 2017 at 03:42:04PM +0800, Eli Qiao wrote:
> > > > > > L3data:0=0xff00;...
> > > > > > L3code:0=0xff00;...
> > > > > >  
> > > > > > * Would you please help to test if the functions work.
> > > > >  
> > > > > Setting up CDP machine.
> > > > >  
> > > > > Unrelated:
> > > > >  
> > > > > Found a bug:
> > > > >  
> > > > > The code should scan for all directories in resctrlfs,
> > > > > and then find free CBM space from that:
> > > > >  
> > > > >  
> > > > > free_cbm_space = ~(resctrldir1.CBM_bits &
> > > > > resctrldir2.CBM_bits &
> > > > > ...
> > > > > resctrldirN.CBM_bits)
> > > > >  
> > > > > For all resctrlfs directories.
> > > > >  
> > > > > The bug is as follows:
> > > > >  
> > > > > Create a directory in resctrlfs by hand:
> > > > >  
> > > > > # mkdir newres
> > > >  
> > > > Libvirt will not aware this after it starts running, so we should not allow operate /sys/fs/.
> > >  
> > > Are you saying that usage of the resctrlfs filesystem should not be
> > > allowed after libvirt starts? I don't think this is correct.
> > >  
> >  
> >  
> > In some cases the only way to accomplish keeping consistency would be
> > saying that if you are using libvirt, you should not change anything
> > behind its back. It would be really wrong in this case, mainly when you
> > need to set the allocation for other apps, especially when there is
> > nicely designed file that you can lock.
> >  
> > > > we will scan for all directors while the libvirt daemon begin running, and libvirt will remove exist directories if no tasks inside of it.
> >  
> > Definitely not. What if someone wants to create another allocation?
> > They start by creating a directory, then libvirtd removes it before they
> > manage to add anything to tasks.
> >  
>  
>  
> If the other application is properly using the filesystem lock, then:  
>  
> OTHER APP, CREATE PROCEDURE:
>  
> 1. grab fs lock.
> 2. create directory.
> 3. write schemata.
> 4. write tasks.
> 5. release fs lock
>  
> Any operation that writes to any file in resctrlfs will first grab  
> the lock. So the problem being discussed is handled.
>  
Sure, as long as the application can manage the schemata well.  
>  
> > >  
> > >  
> > > >  
> > > >  
> > > > > # cd newres
> > > > > # echo "L3:0=3;1=f0000" > schemata
> > > > > # virsh start guest
> > > > > # cd ../b4c270b5-e0f9-4106-a446-69032872ed7e
> > > > > # cat schemata
> > > > > L3:0=3;1=f0000
> > > > >  
> > > > > That is, it is using the same CBM space as the "newres"
> > > > > reservation.
> > > > >  
> > > >  
> > > >  
> > > >  
> > > > As user create a new directory after libvirt running, it don’t notice newly created directory under /sys/fs/resctrl.
> > > >  
> > > > That will lead mess, this should be forbidden.
> > >  
> > > Well, this means that only libvirt can use the resctrlfs filesystem.
> > >  
> > > This forbids other applications which require allocation
> > > of CAT resources from being used.
> > >  
> > > Its simple to fix it: move the scanning of resctrlfs data from libvirt
> > > initialization time to:
> > >  
> > > - VM initialization time
> > > and
> > > - virConnectGetCapabilities time
> > >  
> > > 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)
> >  
>  
>  
> Ok so resctrlfs has to be rescanned in whatever location the
> free size is reported to the user.
>  
>  

Sure, will add this when adding cache free API.  

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