From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752847AbbC3KI0 (ORCPT ); Mon, 30 Mar 2015 06:08:26 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:5619 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752807AbbC3KIV (ORCPT ); Mon, 30 Mar 2015 06:08:21 -0400 X-IronPort-AV: E=Sophos;i="5.04,848,1406563200"; d="scan'208";a="89887850" Message-ID: <55191C3D.8070800@cn.fujitsu.com> Date: Mon, 30 Mar 2015 17:49:49 +0800 From: Gu Zheng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kamezawa Hiroyuki 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> In-Reply-To: <551436F2.5020804@jp.fujitsu.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.100] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Regards, Gu > > 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 > > . >