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. 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 ?
It seems to me that the only reason cpuset information is being treated
as more than tuning is due to an artifact of Xen (i.e., it must be
specified at domain creation). For KVM, for example, I believe this can
be specified after domain creation.
From a libvirt perspective, I think the XML config/tuning split should
be hypervisor-neutral, and based solely on what is required to get a
domain running (ignoring performance):
1) XML contains arguments absolutely needed to start a domain in any
hypervisor. This could be thought of as the minimum requirements for
starting a domin.
2) Tuning information contains arguments that affect performance, and
may be changed.
When a domain is started, the caller can specify a minimal start (XML
only) or a tuned start (XML plus tuning). Lower level libvirt code would
understand the specifics of the hypervisor well enough to know whether
it had to include some of the tuning information at domain creation time.
Daniel
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@xxxxxxxxxx
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list