Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option
Anthony Liguori <anthony(a)codemonkey.ws> writes:
Markus Armbruster <armbru(a)redhat.com> writes:
> Related: overwrite something you got from a config file on the command
> line.
>
> In both your example and mine, we have entirely separate options, and
> they have perfectly ordinary overwrite semantics: each option overwrites
> the given keys with the given values. The last key=value wins.
>
> This usage makes sense, and we obviously want to preserve it.
>
> Paolo's example is different only in that it's a silly. Preserving
> compatibility may mean that once we accepted silly usage, we can't ever
> reject it. Debatable. Personally, I disagree: I think we could outlaw
> repeating keys within the same option argument / configuration file
> section just fine.
>
> Finally, I don't think that we must have fancy-pants syntax to remind
> users that they're configuring a list. What's the chance of confusion
> there? What user would expect num_queues=1,num_queues=2 to make
> num_queues magically become a list?
My fundamental problem here is that we have the same syntax with
different meanings depending on the context.
Going back to our original example:
qemu -numa node,nodeid=2,cpus=4
This is certainly ambiguous. Does this mean that you have a single cpu
for the node (VCPU 4) or does it mean the node have 4 cpus (presumably
ranged 0-3).
Root cause: the name "cpus" can be interpreted as "number of cpus" or
as
"list of cpus". Fix (if it's worth fixing): use a better name. First
one that crossed my mind: "cpu".
Given that ambiguity the following:
qemu -numa node,nodeid=2,cpus=4,cpus=8
Does help the situation. A reasonable person could assume that cpus=8
overrides the previous cpus=4 (as it does elsewhere in QEMU) and
I suspect a reasonable person is blissfully unaware of the fact that he
can give the same key several times in a single option argument, let
alone what happens when he does. And I still think we could outlaw such
repetition if we cared.
Besides the command line, there's also the config file. As Paolo
explained, "repeated key means list" is established practice there.
therefore assume they were creating a node with 8 CPUS (0-7) instead
of
two cpus. However:
qemu -numa node,nodeid=2,cpus=4:8
Is much less ambiguous. Granted, it's not immediately obvious whether
this is a range specification or a disjoint specification but it's more
clear than the previous syntax.
Does it mean CPU 4 and 8? CPU 4 to 8? 8 CPUs starting with 4?
If it's less ambiguous, then probably because it's sufficiently greek to
make people reach for the manual :)
Moreover, no change, thus no improvement for your original example
"cpus=4", which you called "certainly ambigous".