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?

> 

Reply via email to