-- 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.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list