From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752012AbbCaGJp (ORCPT ); Tue, 31 Mar 2015 02:09:45 -0400 Received: from mgwkm04.jp.fujitsu.com ([202.219.69.171]:29161 "EHLO mgwkm04.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751095AbbCaGJn (ORCPT ); Tue, 31 Mar 2015 02:09:43 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2 Message-ID: <551A3A01.7030707@jp.fujitsu.com> Date: Tue, 31 Mar 2015 15:09:05 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gu Zheng CC: Tejun Heo , , , , , Subject: Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed References: <1427336275-32066-1-git-send-email-guz.fnst@cn.fujitsu.com> <55137935.5080301@jp.fujitsu.com> <55139340.8070201@cn.fujitsu.com> <20150326151850.GD1953@htj.duckdns.org> <551436F2.5020804@jp.fujitsu.com> <55191C3D.8070800@cn.fujitsu.com> In-Reply-To: <55191C3D.8070800@cn.fujitsu.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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