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

Martin Kletzander mkletzan at redhat.com
Wed Mar 15 19:49:57 UTC 2017


On Wed, Mar 15, 2017 at 02:11:23PM -0300, Marcelo Tosatti wrote:
>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.
>

Yes, it will automatically fail when you can't do the same allocations,
that's easy.  The difference with host_id is that you cannot foresee
whether keeping the host_id makes sense on the destination as well.

>> 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).
>
>

So we at least need a check for the fact that either the caches are the
somehow same or destination XML is supplied.

The other option would be what I hinted above, that is to change
host_id= to something like level, scope, and pcpu(s)/socket(s).  That is
fairly easy change from the code point of view, but I'm trying to think
more about the user experience.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170315/89db0a46/attachment-0001.sig>


More information about the libvir-list mailing list