Re: The problem of the definition of tuning informations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 08, 2007 at 03:41:12PM -0600, Ryan Harper wrote:
> * Daniel Veillard <veillard@xxxxxxxxxx> [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@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]