Daniel Veillard wrote: > On Thu, Nov 08, 2007 at 02:00:10PM -0600, Ryan Harper wrote: > >> * Daniel Veillard <veillard@xxxxxxxxxx> [2007-11-08 10:08]: >> >>> I promised that mail for the beginning of the week but I still have >>> I think tuning informations are that set of parameters associated >>> to a domain or a host, which are not stricly needed to get the >>> domain(s) working but improve their runtime behaviour. >>> To me this includes: >>> - scheduling parameters the scope may be host/hypervisor/domain >>> - vcpu affinity i.e. to which set of physical CPU each of the >>> vcpu may be bound >>> - and possibly others ... >>> >>> The problem: >>> ------------ >>> People would like to associate those to the XML domain informations, >>> the goal being to be able to restore those informations when a domain >>> (re-)starts. >>> I have been objecting it so far because, I think those informations >>> don't have the same lifetime and scope as the other domain informations >>> saved in the XML. Since they are not needed to start the domain, and >>> that once the domain is started the existing domain API can be used >>> to change those informations, it is better to keep them separate. >>> >> For at least (maybe only) Xen NUMA systems, the application of "tuning" >> information after a domain is started does not achieve the same affect >> as including the information during the initial construction of the >> domain. In particular, Xen needs to know which physical cpus are being >> used to determine which cpus it from which numanode it will allocate >> memory. Adjusting affinity after the domain has allocated memory >> doesn't allow libvirt or any management app to control from which node >> domains pull memory. >> > > 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 > dynamically without (serious) performance penalty. > > >> 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. Well said Daniel - a simple point I was missing. I repeal my objection [1]. Thanks, Jim [1] https://www.redhat.com/archives/libvir-list/2007-November/msg00003.html -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list