Thread (57 messages) 57 messages, 7 authors, 2019-10-30

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

From: Yunsheng Lin <hidden>
Date: 2019-09-25 09:14:43
Also in: linux-mips, linux-s390, linux-sh, linuxppc-dev, lkml, sparclinux

On 2019/9/24 21:19, Michal Hocko wrote:
On Tue 24-09-19 14:59:36, Peter Zijlstra wrote:
quoted
On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote:
quoted
On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote:
quoted
On Tue 24-09-19 14:09:43, Peter Zijlstra wrote:
quoted
quoted
We can push back and say we don't respect the specification because it
is batshit insane ;-)
Here is my fingers crossed.

[...]
quoted
Now granted; there's a number of virtual devices that really don't have
a node affinity, but then, those are not hurt by forcing them onto a
random node, they really don't do anything. Like:
Do you really consider a random node a better fix than simply living
with a more robust NUMA_NO_NODE which tells the actual state? Page
allocator would effectivelly use the local node in that case. Any code
using the cpumask will know that any of the online cpus are usable.
For the pmu devices? Yes, those 'devices' aren't actually used for
anything other than sysfs entries.

Nothing else uses the struct device.
The below would get rid of the PMU and workqueue warnings with no
side-effects (the device isn't used for anything except sysfs).
Hardcoding to 0 is simply wrong, if the node0 is cpuless for example...
Hi, Peter & Michal

From the discussion above, It seems making the node_to_cpumask_map()
NUMA_NO_NODE aware is the most feasible way to move forwad.

Any suggestion?
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help