Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed

[Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On 2015/03/30 18:49, Gu Zheng wrote:
> Hi Kame-san,
>
> On 03/27/2015 12:42 AM, Kamezawa Hiroyuki wrote:
>
>> On 2015/03/27 0:18, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Thu, Mar 26, 2015 at 01:04:00PM +0800, Gu Zheng wrote:
>>>> wq generates the numa affinity (pool->node) for all the possible cpu's
>>>> per cpu workqueue at init stage, that means the affinity of currently un-present
>>>> ones' may be incorrect, so we need to update the pool->node for the new added cpu
>>>> to the correct node when preparing online, otherwise it will try to create worker
>>>> on invalid node if node hotplug occurred.
>>>
>>> If the mapping is gonna be static once the cpus show up, any chance we
>>> can initialize that for all possible cpus during boot?
>>>
>>
>> I think the kernel can define all possible
>>
>>   cpuid <-> lapicid <-> pxm <-> nodeid
>>
>> mapping at boot with using firmware table information.
>
> Could you explain more?

you can scan firmware's table and store all provided information for possible cpus/pxms
somewhere even while future cpus/mems are not onlined rather than determine them
on demand.
But this may be considered as API change for most hot-add users.

So, for now, I vote for detemining ids at online but record it is a good way.

Thanks,
-Kame