Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements

["Andreas Färber" <afaerber@suse.de>]

Am 05.03.2014 12:30, schrieb Paolo Bonzini:
> Il 05/03/2014 12:05, Andreas Färber ha scritto:
>> Am 04.03.2014 15:00, schrieb Paolo Bonzini:
>>> This series includes all the pending work on QOMifying the memory
>>> backends.
>> [snip]
>>
>> There's also a recent RFC from Chen Fan about how to model the
>> association between NUMA nodes and CPU socket/core/thread that
>> would/should influence this series if we're aiming for 2.1 now.
> 
> I don't think it should, apart from conflicts.  This series only changes
> things about memory.  CPUs are handled the same before and after the
> patches.
> 
>> I didn't review it in-depth yet, but minor technical issues apart, I
>> think we need to keep NUMA and CPU separate,
> 
> I agree.

Here you agreed ...

>> Compare that to:
>>
>> /machine
>>   /node[0] # This is not really telling!
>>     /socket[0]
>>       /core[0]
>>         /thread[0] # So CPUState != thread?
>>           cpu -> /machine/unassigned/device[0]
>>   /unassigned
>>     /device[0]
> 
> I think this is better; in our world we can have multiple sockets in the
> same NUMA node.  But CPUState == thread, so you can have just /thread[0]
> -> /machine/unassigned/device[0].

... but you seem to have missed my point about separation. Here the
socket object is a child<> of the NUMA node and would get realized
together with it but separate from the link<>ed CPUState.

> Alternatively, and to keep CPU + NUMA even *more* separate:
> 
>   /machine
>     /node[0]
>        /cpu[0] -> /machine/unassigned/device[0]
>        ...
>     /socket[0]
>        /core[0]
>           /thread[0] -> /machine/unassigned/device[0]
>     /unassigned
>        /device[0]

Now this is pretty much my proposal ;) except that you retained the
criticized "node" as name and moved "socket[0]" out of
/machine/unassigned (I had /machine/peripheral in mind for -device) and
keep the CPUState out of the socket object.

Anthony had requested hot-add to happen via "device_add Xeon4242",
adding a full socket object with 6 cores at once. In that case CPUState
needs to be an integral part of that socket-derived device for recursive
realization. Objects that are just link<>ed to wouldn't get
automatically realized.

Since the only two other places for creating an X86CPU are PC code plus
cpu-add I don't envision problems with adding it as child<> to its core.

>> which then brings up the
>> question Chen Fan asked about whether we need to support splitting CPU
>> threads of one core or CPU cores of one socket onto different NUMA
>> nodes. If we can stop supporting this, 2.0 would be a good point in time
>> to catch this with an error message at least, even if the remodeling
>> depending on it happens post-2.0.
> 
>> Note that according to my interpretation of QOM ABI stability rules we
>> can't just turn a link<cpu> into a child<cpu> without renaming, thus
>> trying to be forward-looking for where we want to go design-wise.
> 
> I think we can.  Children and links look exactly the same from the outside.

Well, we can't qom-get/qom-set a path string from/to a child<> property,
can we? But paths can indeed be resolved either way.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg