From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752745AbbCZQnU (ORCPT ); Thu, 26 Mar 2015 12:43:20 -0400 Received: from mgwkm04.jp.fujitsu.com ([202.219.69.171]:18686 "EHLO mgwkm04.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751807AbbCZQnR (ORCPT ); Thu, 26 Mar 2015 12:43:17 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2 Message-ID: <551436F2.5020804@jp.fujitsu.com> Date: Fri, 27 Mar 2015 01:42:26 +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: Tejun Heo , Gu Zheng CC: , , , , 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> In-Reply-To: <20150326151850.GD1953@htj.duckdns.org> 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/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. One concern is current x86 logic for memory-less node v.s. memory hotplug. (as I explained before) My idea is step1. build all possible mapping at boot cpuid <-> apicid <-> pxm <-> node id at boot. But this may be overwritten by x86's memory less node logic. So, step2. check node is online or not before calling kmalloc. If offline, use -1. rather than updating workqueue's attribute. Thanks, -Kame