[libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option
Markus Armbruster
armbru at redhat.com
Thu Feb 28 17:34:38 UTC 2013
Anthony Liguori <anthony at codemonkey.ws> writes:
> Markus Armbruster <armbru at 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".
More information about the libvir-list
mailing list