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/ :|