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 <isimatu.yasu...@jp.fujitsu.com> >> Signed-off-by: Gu Zheng <guz.f...@cn.fujitsu.com> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
