linux-kernel - Re: [RESEND RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 25 Apr 2015 18:14:52 +0800
From:	Hanjun Guo <guohanjun@...wei.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Gu Zheng <guz.fnst@...fujitsu.com>
CC:	<linux-kernel@...r.kernel.org>, <tj@...nel.org>,
	<mingo@...hat.com>, <x86@...nel.org>, <akpm@...ux-foundation.org>,
	<hpa@...or.com>, <linux-acpi@...r.kernel.org>,
	<laijs@...fujitsu.com>, <isimatu.yasuaki@...fujitsu.com>,
	<kamezawa.hiroyu@...fujitsu.com>, <tangchen@...fujitsu.com>,
	<izumi.taku@...fujitsu.com>
Subject: Re: [RESEND RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid
 mapping persistent

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