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). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
