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

Re: [Libvir] [PATCH] Xen: Support cpu_weight and cpu_cap for Xen.



Daniel Veillard wrote:
On Fri, Oct 26, 2007 at 12:15:38PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
So you are suggesting to add this to the XML, while for me this makes little
sense because of all this specificity.
I have no doubt the patch would 'work' for you, but anybody using a different hypervisor, or different scheduler, or even someone trying to understand what those fields are would have no use or informations (your patch does not provide
documentation for the meaning of those attributes).

 I have a problem with extending the XML in a way which makes sense
only for one hypervisor, when using a specific scheduler, and without
a proper definition for what the extension actually means. Also Those informations are highly runtime dependant, it's tuning,
it is not critical at all to get that tuning to get the domain up and
running, and once it is running you can actually use the libvirt API
to make the scheduler tuning.

 Can you explain why you absolutely want to have that tuning information
in the XML itself ?
There's certainly a general problem here: how do we persist information like CPU pinning and scheduler information across domain shutdown to the next time that the domain starts up. What is the current thinking about setting CPU pinning info when a domain boots?

  To me that's the same thing, CPU pinning and scheduler information are
basically tuning informations. Maybe this is static, maybe this needs to
change frequently, but we cannot assume the first case for the design.

  What would make more sense to me is to be able to save and restore
tuning informations, per domain or for the full system at the virsh level. For example something like:
   virsh savetuning > tuning.data
   or
   virsh savetuning domain > tuning.data

 and

   virsh loadtuning tuning.data

  This would still be convenient for the user, especially for locked systems
or systems where multiple different workload can be used depending on the
demand, one would just need to save tuning for each of them. Tuning could be
reloaded or readjusted ech time a domain is stopped/started or the whole node
is rebooted.
  The implementation could be done entierely in libvirt without having
to change or extend existing APIs or behaviour.

  I can understand the need to make it easy for an user, I still don't
think this means those tuning informations need to be associated to the
domain definition, to me it is somehow orthogonal to the domain themselves
and I would rather try to provide a good solution to the problem, than
try to imitate how Xen was doing that.

[Resurrecting this old thread ...]

How about this as a plan?

(1) Add 'virsh savetuning' and 'virsh loadtuning' commands as Daniel Veillard has suggested above. These would save the per-domain tuning information to an XML file

  <tuning>
    <pin vcpu="0" pcpu="0"/>
    <pin vcpu="1" pcpu="1"/>
    <!-- other stuff for cpu_weight, etc. -->
  </tuning>

(2) Modify 'virsh define' and 'virsh create' commands to add a '--with-tuning' flag, so that:

  virsh define foo.xml --with-tuning foo-tuning.xml

Which basically does the ordinary 'virsh define' step followed by 'virsh loadtuning'.

(3) Modify 'virsh save' to add '--save-tuning', so that:

  virsh save foo foo.img --save-tuning foo-tuning.xml

This captures the tuning information into the XML file, and is the same as doing an ordinary 'save' followed by 'virsh savetuning'.

	- - -

This doesn't change the libvirt API, nor does it deal with saving and restoring tuning information across restarts (but then I can't see how the autostart flag works for Xen at the moment at all ... a bug?)

I'm prepared to do this work if people think it's a good idea.

Rich.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


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