This translates to the following resctrltool-style reservations:
res.vm-a.vcpu-2
type=both,size=VM-A-RESSIZE,cache-id=0
res.vm-b.vcpu-2
type=both,size=VM-B-RESSIZE,cache-id=0
Which translate to the following in resctrlfs:
res.vm-a.vcpu-2
type=both,size=VM-A-RESSIZE,cache-id=0 type=both,size=default-size,cache-id=1 ...
res.vm-b.vcpu-2
type=both,size=VM-B-RESSIZE,cache-id=0 type=both,size=default-size,cache-id=1 ...
if we specified cache-id while specify size without thinking the already existed vcpu->pcpu affinity, cache allocation will be useless. a VM is pinged to socket 1 (which cache_id should be 1) but while specify cache resource , user specify the cache-id=0. since the vm won't be scheduled to socket 0, the cache allocated on socket 0 (cache_id=0) will not be used. I suggest to let libvirt detect if the cache-id.
Which is what we want, since the VCPUs are pinned.
res.vm-a.vcpu-1 and res.vm-b.vcpu-1 don't need to be assigned to any reservation, which means they'll remain on the default group.
You've showing type=both here which IIUC, means data and instruction cache.
No, type=both is non-cdp hosts (data and instructions reservations shared).
type=data,type=code is for cdp hosts (data and instructions reservations separate).
Is that configuring one cache that serves both purposes ?
Yes.
Do we need to be able to configure them independantly.
Yes.
RESTRICTIONS TO THE SYNTAX ABOVE ================================
Rules for the parameters: * type=code must be paired with type=data entry.
What does this mean exactly when configuring guests ? Do we have to configure data + instruction cache on the same cache ID, do they have to be the same size, or are they completely independant ?
This means that a user can't specify this reservation:
type=data,size=10mb,cache-id=1
They have to specify _both_ code and data sizes:
type=data,size=10mb,cache-id=1; type=code,size=2mb,cache-id=1
Now a single both reservation is valid:
type=both,size=10mb,cache-id=1
ABOUT THE LIST INTERFACE ========================
About an interface for listing the reservations of the system to OpenStack.
I think that what OpenStack needs is to check, before starting a guest on a given host, that there is sufficient space available for the reservation.
To do that, it can:
1) resctrltool list (the end of the output mentions how much free space available there is), or via resctrlfs directly (have to lock the filesystem, read each directory, AND each schemata, and count number of zero bits). 2) Via libvirt
Should fix resctrltool/API to list amount of contiguous free space
OpenStack, should just use libvirt APIs exclusively - there should not be any need for it to use other tools if we've designed the libvirt API correctly.
Got it.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Best regards - Eli 天涯无处不重逢 a leaf duckweed belongs to the sea , where not to meet in life