[lkml]   [2015]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed
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.


 \ /
  Last update: 2015-03-31 08:41    [W:0.098 / U:18.064 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site