[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.


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