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

[Daniel P. Berrange]

On Thu, Jan 12, 2017 at 10:58:53AM +0800, 乔立勇(Eli Qiao) wrote:
> 2017-01-11 19:09 GMT+08:00 Daniel P. Berrange <berrange at redhat.com>:
> 
> > On Wed, Jan 11, 2017 at 11:55:28AM +0100, Martin Kletzander wrote:
> > > On Wed, Jan 11, 2017 at 10:05:26AM +0000, Daniel P. Berrange wrote:
> > > >
> > > > IIUC, the kernel lets us associate individual PIDs
> > > > with each cache. Since each vCPU is a PID, this means
> > > > we are able to allocate different cache size to
> > > > different CPUs. So we need to be able to represent
> > > > that in the XML. I think we should also represent
> > > > the allocation in a normal size (ie KiB), not in
> > > > count of min unit.
> > > >
> > > > So eg this shows allocating two cache banks and giving
> > > > one to the first 4 cpus, and one to the second 4 cpus
> > > >
> > > >   <cachetune>
> > > >      <bank type="l3" size="5632" unit="KiB" cpus="0,1,2,3"/>
> > > >      <bank type="l3" size="5632" unit="KiB" cpus="4,5,6,7"/>
> > > >   </cachetune>
> > > >
> > >
> > > I agree with your approach, we just need to keep in mind two more
> > > things.  I/O threads and the mail QEMU (emulator) thread can have
> > > allocations as well.  Also we need to say on which socket the allocation
> > > should be done.
> >
> > Also, I wonder if this is better put in the existing <cputune>
> > element, since this is really an aspect of the CPU configuration.
> >
> > Perhaps split configuration of cache banks from the mapping to
> > cpus/iothreads/emulator. Also, per Marcello's mail, we need to
> > include the host cache ID, so we know where to allocate from
> > if there's multiple caches of the same type. So XML could look
> > more like this:
> >
> >    <cputune>
> >        <cache id="1" host_id="2" type="l3" size="5632" unit="KiB"/>
> >        <cache id="2" host_id="4" type="l3" size="5632" unit="KiB"/>
> 
> 
> I don't think we require host_id here. we can only allow setting cache
> allocation only IF the VM has vcpu -> pcpu affinity setting. and let
> libvirt calculate where to set the cache (on which
> cache_id/resource_id/socket_id, the 3 ids are some meaning) since l3 caches
> are cpu's resource, only the VM running on specify cpu can benefit the
> cache.

Lets say the guest is pinned to CPU 3, and there are two separate L3
caches associated with CPU 3. If we don't include host_id, then libvirt
has to decide which of the two possible caches to allocate from. We can
do that, but generally we've tried to avoid such policy decisions in
libvirt before, hence I thought it preferrable to have the admin be
explicit about which cache they want.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|