Messages in this thread | | | Date | Tue, 22 Sep 2009 02:30:34 -0400 (EDT) | From | Christoph Lameter <> | Subject | Re: [RFC PATCH 0/3] Fix SLQB on memoryless configurations V2 |
| |
On Mon, 21 Sep 2009, David Rientjes wrote:
> I disagree that we need kernel support for memoryless nodes on x86 and > probably on all architectures period. "NUMA nodes" will always contain > memory by definition and I think hijacking the node abstraction away from > representing anything but memory affinity is wrong in the interest of a > long-term maintainable kernel and will continue to cause issues such as > this in other subsystems.
Amen. Sadly my past opinions on this did not seem convincing enough.
> I do understand the asymmetries of these machines, including the ppc that > is triggering this particular hang with slqb. But I believe the support > can be implemented in a different way: I would offer an alternative > representation based entirely on node distances. This would isolate each > region of memory that has varying affinity to cpus, pci busses, etc., into > nodes and then report a distance, whether local or remote, to other nodes > much in the way the ACPI specification does with proximity domains.
Good idea.
> Using node distances instead of memoryless nodes would still be able to > represent all asymmetric machines that currently benefit from the support > by binding devices to memory regions to which they have the closest > affinity and then reporting relative distances to other nodes via > node_distance().
How would you deal with a memoryless node that has lets say 4 processors and some I/O devices? Now the memory policy is round robin and there are 4 nodes at the same distance with 4G memory each. Does one of the nodes now become priviledged under your plan? How do you equally use memory from all these nodes?
| |