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

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