[libvirt] [PATCH resend V10 03/12] Resctrl: Add new xml element to support cache tune

Marcelo Tosatti mtosatti at redhat.com
Wed Mar 15 17:11:23 UTC 2017


On Wed, Mar 15, 2017 at 03:59:31PM +0100, Martin Kletzander wrote:
> On Wed, Mar 15, 2017 at 02:23:26PM +0000, Daniel P. Berrange wrote:
> >On Wed, Mar 15, 2017 at 03:11:26PM +0100, Martin Kletzander wrote:
> >>On Mon, Mar 06, 2017 at 06:06:32PM +0800, Eli Qiao wrote:
> >>> This patch adds new xml element to support cache tune as:
> >>>
> >>> <cputune>
> >>>  ...
> >>>  <cachetune id='1' host_id='0' type='l3' size='2816' unit='KiB'
> >>
> >>Again, this was already discussed, probably, I just can't find the
> >>source of it.  But host_id actually already selects what cache is
> >>supposed to be used, so instead of type='l3' we only need scope='both'
> >>(or data/instruction) there.  Or am I missing something?  What I'm
> >>concerned about is that the host_id is mostly stable on one host (when
> >>the previously mentioned problems are fixed), but it will make no sense
> >>when the VM is migrated to another one.

This is the same conditions as pinning a vcpu to a pcpu.

So yes, it might be that you want to migrate to a host where
a different "host ID" number is used (which might or might not
be a different socket).

>   Unfortunately, the only
> >>solution I can think of is using multiple keys to precisely describe the
> >>bank we want (e.g. host's cpu id, cache level and scope), but that seems
> >>very unclean.
> >
> >I tend to view use of this cachetune setting as being similar to
> >using host CPU passthrough - you're intentionally trading off
> >migratability of your  guest to get a perf boost.
> >
> >Even without the host_id bit, this is still non-portable, as you
> >might be requesting separate regions for code + data, but the
> >target host of migration may only support shared regions.

Then migration should fail. 

> Sure, but those are things we can check during migration.  I'd be OK
> with disabling migration (or making it --unsafe) when migrating with
> cachetune.

Migration support is required (for NFV usecase they want to migrate
VMs around).





More information about the libvir-list mailing list