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

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

 



Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]