All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <tj@kernel.org>,
	<laijs@cn.fujitsu.com>, <isimatu.yasuaki@jp.fujitsu.com>,
	<tangchen@cn.fujitsu.com>, <izumi.taku@jp.fujitsu.com>
Subject: Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed
Date: Thu, 26 Mar 2015 13:04:00 +0800	[thread overview]
Message-ID: <55139340.8070201@cn.fujitsu.com> (raw)
In-Reply-To: <55137935.5080301@jp.fujitsu.com>

Hi Kame-san,

On 03/26/2015 11:12 AM, Kamezawa Hiroyuki wrote:

> On 2015/03/26 11:17, Gu Zheng wrote:
>> Yasuaki Ishimatsu found that with node online/offline, cpu<->node
>> relationship is established. Because workqueue uses a info which was
>> established at boot time, but it may be changed by node hotpluging.
>>
>> Once pool->node points to a stale node, following allocation failure
>> happens.
>>    ==
>>       SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
>>        cache: kmalloc-192, object size: 192, buffer size: 192, default
>> order:
>>      1, min order: 0
>>        node 0: slabs: 6172, objs: 259224, free: 245741
>>        node 1: slabs: 3261, objs: 136962, free: 127656
>>    ==
>>
>> As the apicid <--> node relationship is persistent, so the root cause is the
>      ^^^^^^^
>            pxm.
> 
>> cpu-id <-> lapicid mapping is not persistent (because the currently implementation
>> always choose the first free cpu id for the new added cpu), so if we can build
>> persistent cpu-id <-> lapicid relationship, this problem will be fixed.
>>
>> Please refer to https://lkml.org/lkml/2015/2/27/145 for the previous discussion.
>>
>> Gu Zheng (2):
>>    x86/cpu hotplug: make lapicid <-> cpuid mapping persistent
>>    workqueue: update per cpu workqueue's numa affinity when cpu
>>      preparing online
> 
> why patch(2/2) required ?

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.

Regards,
Gu

> 
> Thanks,
> -Kame
> 
>>
>>   arch/x86/kernel/apic/apic.c |   31 ++++++++++++++++++++++++++++++-
>>   kernel/workqueue.c          |    1 +
>>   2 files changed, 31 insertions(+), 1 deletions(-)
>>
> 
> 
> .
> 



  reply	other threads:[~2015-03-26  6:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26  2:17 [PATCH 0/2] workqueue: fix a bug when numa mapping is changed Gu Zheng
2015-03-26  2:17 ` [PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent Gu Zheng
2015-03-26  3:19   ` Kamezawa Hiroyuki
2015-03-26  4:55     ` Gu Zheng
2015-03-26 15:13       ` Tejun Heo
2015-03-26 16:31       ` Kamezawa Hiroyuki
2015-03-30  9:58         ` Gu Zheng
2015-04-01  2:59           ` Kamezawa Hiroyuki
2015-03-26  2:17 ` [PATCH 2/2] workqueue: update per cpu workqueue's numa affinity when cpu preparing online Gu Zheng
2015-03-26  3:12 ` [PATCH 0/2] workqueue: fix a bug when numa mapping is changed Kamezawa Hiroyuki
2015-03-26  5:04   ` Gu Zheng [this message]
2015-03-26 15:18     ` Tejun Heo
2015-03-26 16:42       ` Kamezawa Hiroyuki
2015-03-30  9:49         ` Gu Zheng
2015-03-30  9:49         ` Gu Zheng
2015-03-31  6:09           ` Kamezawa Hiroyuki
2015-03-31 15:28             ` Tejun Heo
2015-04-01  2:55               ` Kamezawa Hiroyuki
2015-04-01  3:02                 ` Tejun Heo
2015-04-01  3:05                   ` Tejun Heo
2015-04-01  8:30                   ` Kamezawa Hiroyuki
2015-04-02  1:36                     ` Gu Zheng
2015-04-02  2:54                       ` Kamezawa Hiroyuki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55139340.8070201@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.