Xen devel - Mar 2012 - x86/dom0: limit dom0_max_vcpus value

This caused particularly poor performance when booting a server in
uniprocessor mode for debugging reasons, and had 4 dom0 vcpus competing
for 1pcpus worth of time.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 12.03.12 at 16:56, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> This caused particularly poor performance when booting a server in
> uniprocessor mode for debugging reasons, and had 4 dom0 vcpus competing
> for 1pcpus worth of time.
NAK. This was intentionally removed in an earlier c/s (and I''m in fact
making use of this for certain types of stress tests). No-one forces
you or anyone else to boot with dom0_max_vcpus=4 when there''s
just a single pCPU.

Jan

On 12/03/12 16:12, Jan Beulich wrote:
>>>> On 12.03.12 at 16:56, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>> This caused particularly poor performance when booting a server in
>> uniprocessor mode for debugging reasons, and had 4 dom0 vcpus competing
>> for 1pcpus worth of time.
> NAK. This was intentionally removed in an earlier c/s (and I''m in
fact
> making use of this for certain types of stress tests). No-one forces
> you or anyone else to boot with dom0_max_vcpus=4 when there''s
> just a single pCPU.
>
> Jan
What is the justification for removing it? c/s 18266:d31546a3883e has no
explanation.

This is now resulting in a command line parameter with "max" in its
name
acting unlike all other "max" parameters.  There is certainly an
argument for introducing a "dom0_cpus" parameter for setting an exact
number, but I feel that this behavior is wrong for a parameter with
"max" in its name.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

>>> On 12.03.12 at 17:32, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 12/03/12 16:12, Jan Beulich wrote:
>>>>> On 12.03.12 at 16:56, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>>> This caused particularly poor performance when booting a server in
>>> uniprocessor mode for debugging reasons, and had 4 dom0 vcpus
competing
>>> for 1pcpus worth of time.
>> NAK. This was intentionally removed in an earlier c/s (and I''m
in fact
>> making use of this for certain types of stress tests). No-one forces
>> you or anyone else to boot with dom0_max_vcpus=4 when there''s
>> just a single pCPU.
>>
>> Jan
> 
> What is the justification for removing it? c/s 18266:d31546a3883e has no
> explanation.
The restriction was artificial, enforcing policy where none should be
enforced.
> This is now resulting in a command line parameter with "max" in
its name
> acting unlike all other "max" parameters.  There is certainly an
> argument for introducing a "dom0_cpus" parameter for setting an
exact
> number, but I feel that this behavior is wrong for a parameter with
> "max" in its name.
No, you misunderstand the ''max'' here: Dom0 can''t ever
grow beyond
that number (see the implementation of XEN_DOMCTL_max_vcpus),
and hence what you specify here _is_ the maximum. If you want less
active ones, you need to bring them _down_ once the system is up
(via the tool stack or kernel interfaces).

Jan