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