Re: [PATCH 1/5] try parent numa_node at first before using default

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Cornelia Huck wrote:
> On Thu, 12 Jul 2007 07:47:52 +0200,
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Also keep in mind that either device_move() should update the numa_node,
>> or the subsystems which call device_move() should explicitly update it
>> on their own.   (Unless they know that their devices will always stay at
>> the same NUMA node even when switching parents.)
> 
> I'd trust the subsystems to know best whether something regarding NUMA
> changed.

Generally,

  - the *subsystems* know about the topology (parent devices, NUMA
    nodes).  The assumption that the child device belongs per default to
    the same NUMA node as its parent device is usually correct, but it
    really is only an assumption.

  - The *drivers* incorporate as much knowledge about topology from the
    subsystem as is necessary e.g. for correct DMA mapping.  E.g. a
    device X on bus B which is attached to controller Y needs DMA
    mapping for device Y, not for device X.  Same, NUMA-optimized
    allocations have to be done for the NUMA node of DMA device Y.  An
    association of device X with a NUMA node is not interesting to the
    driver.  It becomes a bit more difficult if the driver sits between
    two subsystems and that upper-layer subsystem has no flexible API to
    pass up the correct NUMA node.

So, since figuring the correct DMA device out is done by drivers
themselves, they usually can figure out the correct NUMA node as well.
The only precondition is that each DMA device has the correct NUMA node
set.  This is the job of subsystems like PCI, but it may be reasonable
to have simple and broadly applicable helpers for this in the driver core.

So, _is_ the dev->numa_node = dev->parent.numa_node assumption, if
implemented in device_add() and device_move(), as simple and as broadly
applicable as we want driver core's API to be?  Perhaps yes.
-- 
Stefan Richter
-=====-=-=== -=== -==--
http://arcgraph.de/sr/