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

Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

Anthony Liguori <anthony codemonkey ws> writes:

> Markus Armbruster <armbru 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".

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