Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758952AbbDYKPP (ORCPT ); Sat, 25 Apr 2015 06:15:15 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:45883 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753585AbbDYKPL (ORCPT ); Sat, 25 Apr 2015 06:15:11 -0400 Message-ID: <553B691C.2030808@huawei.com> Date: Sat, 25 Apr 2015 18:14:52 +0800 From: Hanjun Guo User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Rafael J. Wysocki" , Gu Zheng CC: , , , , , , , , , , , Subject: Re: [RESEND RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent References: <1429869513-2906-1-git-send-email-guz.fnst@cn.fujitsu.com> <9864973.ZP6z8adBRm@vostro.rjw.lan> In-Reply-To: <9864973.ZP6z8adBRm@vostro.rjw.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.17.188] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2154 Lines: 49 On 2015/4/24 22:45, Rafael J. Wysocki wrote: > On Friday, April 24, 2015 05:58:32 PM 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 <---> pxm and pxm <--> node relationship are persistent, then >> the apicid <--> node mapping is persistent, so the root cause is the >> cpu-id <-> lapicid mapping is not persistent (because the currently implementation >> always choose the first free cpu id for the new added cpu). If we can build >> persistent cpu-id <-> lapicid relationship, this problem will be fixed. >> >> This patch tries to build the whole world mapping cpuid <-> apicid <-> pxm <-> node >> for all possible processor at the boot, the detail implementation are 2 steps: >> Step1: generate a logic cpu id for all the local apic (both enabled and dsiabled) >> when register local apic >> Step2: map the cpu to the phyical node via an additional acpi ns walk for processor. >> >> Please refer to: >> https://lkml.org/lkml/2015/2/27/145 >> https://lkml.org/lkml/2015/3/25/989 >> for the previous discussion. >> >> Reported-by: Yasuaki Ishimatsu >> Signed-off-by: Gu Zheng > This one will conflict with the ARM64 ACPI material when that goes in, so it'll > need to be rebased on top of that. Yes, please. Then I will take a look too. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/