于 2011年03月29日 16:10, Matthias Bolte 写道:
2011/3/29 Daniel Veillard<veillard@redhat.com>:
On Tue, Mar 29, 2011 at 02:32:19PM +0800, Osier Yang wrote:
Sample of cputune xml: <cputune> <shares>2048</shares> <vcpupin vcpu='0' cpuset='0-4,^3'/> <vcpupin vcpu='1' cpuset='1,2'/> </cputune>
* docs/schemas/domain.rng --- docs/schemas/domain.rng | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-)
@@ -2198,6 +2219,17 @@ <param name="minInclusive">1</param> </data> </define> +<define name="vcpuid"> +<data type="unsignedShort"> +<param name="pattern">[0-9]+</param> +</data> +</define> +<define name="cpushares"> +<data type="unsignedInt"> +<param name="pattern">[0-9]+</param> +<param name="maxInclusive">262144</param> +</data> +</define>
So there is a bounded value 262144 for cpushares, good but still no indication of the meaning :-)
Actually for ESX I would want this value to be an unrestricted signed integer. ESX has 3 predefined values: low, normal and high. Currently in the scheduler parameters functions I map them to -1, -2, -3. But I'm not sure if that's a thing we should use as a general pattern. I might also calculate the actual values, instead of using special symbolic values. The vSphere docs contain formulas for this conversion.
Nevertheless, I vote against this arbitrary (cgroup specific?) upper limit.
Hmm, this should make sense, what we need is to give clear documentation for it, and actually libvirt APIs (setSchedualerParameters) doesn't has constaints on this, so I will remove the upper limit. Regards Osier