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