[libvirt] "[V3] RFC for support cache tune in libvirt"

Marcelo Tosatti mtosatti at redhat.com
Wed Jan 11 12:34:03 UTC 2017


On Wed, Jan 11, 2017 at 10:19:10AM -0200, Marcelo Tosatti wrote:
> 
> Hi,
> 
> Comments/questions related to:
> https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html
> 
> 1) root s2600wt:~/linux# virsh cachetune kvm02 --l3.count 2
> 
> How does allocation of code/data look like?
> 
> 2) 'nodecachestats' command:
> 
> 	3. Add new virsh command 'nodecachestats':
> 	This API is to expose vary cache resouce left on each hardware (cpu
> 	socket).
> 	It will be formated as:
> 	<resource_type>.<resource_id>: left size KiB
> 
> Does this take into account that only contiguous regions of cbm masks
> can be used for allocations?
> 
> Also, it should return the amount of free cache on each cacheid.
> 
> 3) The interface should support different sizes for different
> cache-ids. See the KVM-RT use case at 
> https://www.redhat.com/archives/libvir-list/2017-January/msg00415.html
> "WHAT THE USER NEEDS TO SPECIFY FOR VIRTUALIZATION (KVM-RT)".

And when the user specification lacks cacheid of a given socket in
the system, the code should use the default resctrlfs masks
(that is for the default group).

> 4) Usefulness of exposing minimum unit size.
> 
> Rather than specify unit sizes (which forces the user 
> to convert every time the command is executed), why not specify 
> in kbytes and round up?
> 
>       <resctrl name='L3' unit='KiB' cache_size='56320'
> cache_unit='2816'/>
> 
> As noted in item 1 of
> https://www.redhat.com/archives/libvir-list/2017-January/msg00494.html,
> "1) Convertion of kbytes (user specification) --> number of CBM bits
> for host.", 
> the format where the size is stored is kbytes, so its awkward 
> to force users and OpenStack to perform the convertion themselves
> (and zero benefits... nothing changes if you know the unit size).

5) Please perform necessary filesystem locking as described
at Documentation/x86/intel_rdt_ui.txt in the kernel source.





More information about the libvir-list mailing list