[PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

Peter Zijlstra peterz at infradead.org
Thu Sep 26 22:24:06 AEST 2019


On Thu, Sep 26, 2019 at 01:45:53PM +0200, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Thu, Sep 26, 2019 at 11:42 AM Peter Zijlstra <peterz at infradead.org> wrote:
> > On Wed, Sep 25, 2019 at 03:25:44PM +0200, Michal Hocko wrote:
> > > I am sorry but I still do not understand why you consider this whack a
> > > mole better then simply live with the fact that NUMA_NO_NODE is a
> > > reality and that using the full cpu mask is a reasonable answer to that.
> >
> > Because it doesn't make physical sense. A device _cannot_ be local to
> > all CPUs in a NUMA system.
> 
> While it cannot be local to all CPUs, it can be at a uniform (equal) distance
> to each CPU node, can't it?

Only in some really narrow cases; and I'm not sure those are realistic,
nor if then not providing NUMA info is the best way to describe that.

I suppose it is possible to have a PCI bridge shared between two nodes,
such that the PCI devices have equidistance; esp. if that all lives in a
package. But the moment you scale this out, you either get devices that
are 'local' to a package while having multiple packages, or if you
maintain a single bridge in a big system, things become so slow it all
doesn't matter anyway (try having a equidistant device in a 16 node
system).

I'm saying that assigning a node (one of the shared) is, in the generic
ase of multiple packages, the better solution over assigning all nodes.

The other solution is migrating the device model over to a node mask,
instead of a single node. But like said; I'm not sure anybody actually
build something like this. So I'm not sure it matters.

OTOH allowing to not describe NUMA has led to a whole host of crap,
which if we don't become stricter will only get worse.


More information about the Linuxppc-dev mailing list