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

Re: [libvirt] [PATCH 1/8] cputune: Add xml schema for cputune xml



于 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


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