[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





-- 
Eli Qiao
Sent with Sparrow

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. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]