Re: [libvirt] [PATCH resend V10 03/12] Resctrl: Add new xml element to support cache tune
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).