From: Tang Chen <tangchen@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: cl@linux.com, jiang.liu@linux.intel.com,
mika.j.penttila@gmail.com, mingo@redhat.com,
akpm@linux-foundation.org, rjw@rjwysocki.net, hpa@zytor.com,
yasu.isimatu@gmail.com, isimatu.yasuaki@jp.fujitsu.com,
kamezawa.hiroyu@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
gongzhaogang@inspur.com, x86@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent.
Date: Tue, 24 Nov 2015 15:13:28 +0800 [thread overview]
Message-ID: <56540E18.3030109@cn.fujitsu.com> (raw)
In-Reply-To: <20151123220451.GG19072@mtj.duckdns.org>
On 11/24/2015 06:04 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Nov 19, 2015 at 12:22:10PM +0800, Tang Chen wrote:
>> [Solution]
>>
>> There are four mappings in the kernel:
>> 1. nodeid (logical node id) <-> pxm
>> 2. apicid (physical cpu id) <-> nodeid
>> 3. cpuid (logical cpu id) <-> apicid
>> 4. cpuid (logical cpu id) <-> nodeid
>>
>> 1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <-> pxm
>> mapping is setup at boot time. This mapping is persistent, won't change.
>>
>> 2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at boot
>> time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is also
>> persistent.
>>
>> 3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
>> allocated, lower ids first, and released at CPU hotremove time, reused for other
>> hotadded CPUs. So this mapping is not persistent.
>>
>> 4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
>> cleared at CPU hotremove time. As a result of 3, this mapping is not persistent.
>>
>> To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
>> cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
>> cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <-> apicid
>> mapping. So the key point is obtaining all cpus' apicid.
> I don't know much about acpi so can't actually review the patches but
> the overall approach looks good to me.
Thank you, TJ. Will test it recently.
>
> Thanks.
>
--
This message has been scanned for viruses and
dangerous content by Fujitsu, and is believed to be clean.
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: cl@linux.com, jiang.liu@linux.intel.com,
mika.j.penttila@gmail.com, mingo@redhat.com,
akpm@linux-foundation.org, rjw@rjwysocki.net, hpa@zytor.com,
yasu.isimatu@gmail.com, isimatu.yasuaki@jp.fujitsu.com,
kamezawa.hiroyu@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
gongzhaogang@inspur.com, x86@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent.
Date: Tue, 24 Nov 2015 15:13:28 +0800 [thread overview]
Message-ID: <56540E18.3030109@cn.fujitsu.com> (raw)
In-Reply-To: <20151123220451.GG19072@mtj.duckdns.org>
On 11/24/2015 06:04 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Nov 19, 2015 at 12:22:10PM +0800, Tang Chen wrote:
>> [Solution]
>>
>> There are four mappings in the kernel:
>> 1. nodeid (logical node id) <-> pxm
>> 2. apicid (physical cpu id) <-> nodeid
>> 3. cpuid (logical cpu id) <-> apicid
>> 4. cpuid (logical cpu id) <-> nodeid
>>
>> 1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <-> pxm
>> mapping is setup at boot time. This mapping is persistent, won't change.
>>
>> 2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at boot
>> time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is also
>> persistent.
>>
>> 3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
>> allocated, lower ids first, and released at CPU hotremove time, reused for other
>> hotadded CPUs. So this mapping is not persistent.
>>
>> 4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
>> cleared at CPU hotremove time. As a result of 3, this mapping is not persistent.
>>
>> To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
>> cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
>> cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <-> apicid
>> mapping. So the key point is obtaining all cpus' apicid.
> I don't know much about acpi so can't actually review the patches but
> the overall approach looks good to me.
Thank you, TJ. Will test it recently.
>
> Thanks.
>
--
This message has been scanned for viruses and
dangerous content by Fujitsu, and is believed to be clean.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: <cl@linux.com>, <jiang.liu@linux.intel.com>,
<mika.j.penttila@gmail.com>, <mingo@redhat.com>,
<akpm@linux-foundation.org>, <rjw@rjwysocki.net>, <hpa@zytor.com>,
<yasu.isimatu@gmail.com>, <isimatu.yasuaki@jp.fujitsu.com>,
<kamezawa.hiroyu@jp.fujitsu.com>, <izumi.taku@jp.fujitsu.com>,
<gongzhaogang@inspur.com>, <x86@kernel.org>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>
Subject: Re: [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent.
Date: Tue, 24 Nov 2015 15:13:28 +0800 [thread overview]
Message-ID: <56540E18.3030109@cn.fujitsu.com> (raw)
In-Reply-To: <20151123220451.GG19072@mtj.duckdns.org>
On 11/24/2015 06:04 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Nov 19, 2015 at 12:22:10PM +0800, Tang Chen wrote:
>> [Solution]
>>
>> There are four mappings in the kernel:
>> 1. nodeid (logical node id) <-> pxm
>> 2. apicid (physical cpu id) <-> nodeid
>> 3. cpuid (logical cpu id) <-> apicid
>> 4. cpuid (logical cpu id) <-> nodeid
>>
>> 1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <-> pxm
>> mapping is setup at boot time. This mapping is persistent, won't change.
>>
>> 2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at boot
>> time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is also
>> persistent.
>>
>> 3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
>> allocated, lower ids first, and released at CPU hotremove time, reused for other
>> hotadded CPUs. So this mapping is not persistent.
>>
>> 4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
>> cleared at CPU hotremove time. As a result of 3, this mapping is not persistent.
>>
>> To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
>> cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
>> cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <-> apicid
>> mapping. So the key point is obtaining all cpus' apicid.
> I don't know much about acpi so can't actually review the patches but
> the overall approach looks good to me.
Thank you, TJ. Will test it recently.
>
> Thanks.
>
--
This message has been scanned for viruses and
dangerous content by Fujitsu, and is believed to be clean.
next prev parent reply other threads:[~2015-11-24 7:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 4:22 [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` [PATCH v3 1/5] x86, memhp, numa: Online memory-less nodes at boot time Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` [PATCH v3 2/5] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus " Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` [PATCH v3 3/5] x86, acpi, cpu-hotplug: Introduce cpuid_to_apicid[] array to store persistent cpuid <-> apicid mapping Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` [PATCH v3 4/5] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:22 ` [PATCH v3 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting Tang Chen
2015-11-19 4:22 ` Tang Chen
2015-11-19 4:32 ` [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent Tang Chen
2015-11-19 4:32 ` Tang Chen
2015-11-23 22:04 ` Tejun Heo
2015-11-23 22:04 ` Tejun Heo
2015-11-24 7:13 ` Tang Chen [this message]
2015-11-24 7:13 ` Tang Chen
2015-11-24 7:13 ` Tang Chen
2015-12-09 21:10 ` Yasuaki Ishimatsu
2015-12-09 21:10 ` Yasuaki Ishimatsu
2015-12-10 1:50 ` Tang Chen
2015-12-10 1:50 ` Tang Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56540E18.3030109@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=gongzhaogang@inspur.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=jiang.liu@linux.intel.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mika.j.penttila@gmail.com \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yasu.isimatu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.