[Libvir] The problem of the definition of tuning informations
Daniel Veillard
veillard at redhat.com
Thu Nov 8 21:57:54 UTC 2007
On Thu, Nov 08, 2007 at 03:41:12PM -0600, Ryan Harper wrote:
> * Daniel Veillard <veillard at redhat.com> [2007-11-08 15:27]:
> > yes, I understand and that's why I agreed to add the cpuset information
> > at that point it's more than tunning because it may be irreversible for the
> > lifetime of the domain, so this really should be in the XML. I'm not
> > suggesting to go back about 'cpu affinity' i.e. to which physical CPUs
> > a domain should be bound, but 'vcpu affinity' i.e. then how the virtual
> > CPUs of the domain are mapped onto that cpu set, that can change
>
> OK, I see your distinction here.
okay, good this is clarified, bear with me it's not always simple
to try to explain this kind of things :-)
> > dynamically without (serious) performance penalty.
>
> At least for Xen, the 'cpu' affinity specified with a domain is
> only accessible via the xen config file and is not enforced in any way
> such that it prevents from someone "tuning" a domain to use physical
> cpus outside of the specified cpumap. Users can can certainly
> specify a cpu outside of the original cpuset from the config file which
> in a NUMA scenario has the potential for serious performance penalties.
Well all tuning parameters I can think of can actually harm the
system, actually if there was no drawback possible they would be
integrated in the system default mechanism I guess :-)
> >
> > > I don't have any objection to separating "tuning" information as long as
> > > we have the ability to merge permanent domain parameters with its
> > > "tuning" information prior to domain construction.
> >
> > My point is that you don't need the tuning informations to create the
> > domain, if you need them it's not tuning. When you say you want to
> > merge them, do you want this to create the domain ? It should not
> > be necessary (or I take a counter example that would help me), right ?
>
> I agree here. I was lumping cpuset info into your tunable category but
> you clarified the distinction above. I just want to ensure that initial
> cpuset mapping is present prior to constructing a domain as that is
> integral for proper Xen NUMA memory allocation.
okay, sure, that's clear in my mind but wasn't clear in my wording,
I hope there is no other issue.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list
mailing list