qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements
Date: Wed, 05 Mar 2014 12:30:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.

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].

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]

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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]