Re: [RFC PATCH 0/3] Fix SLQB on memoryless configurations V2

[Christoph Lameter]

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?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/