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