From: Tang Chen <tangchen@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: mingo@redhat.com, akpm@linux-foundation.org, rjw@rjwysocki.net,
hpa@zytor.com, laijs@cn.fujitsu.com, yasu.isimatu@gmail.com,
isimatu.yasuaki@jp.fujitsu.com, kamezawa.hiroyu@jp.fujitsu.com,
izumi.taku@jp.fujitsu.com, gongzhaogang@inspur.com,
qiaonuohan@cn.fujitsu.com, x86@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 0/5] Make cpuid <-> nodeid mapping persistent.
Date: Thu, 23 Jul 2015 12:44:53 +0800 [thread overview]
Message-ID: <55B07145.5010404@cn.fujitsu.com> (raw)
In-Reply-To: <20150715221345.GO15934@mtj.duckdns.org>
On 07/16/2015 06:13 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 07, 2015 at 05:30:20PM +0800, Tang Chen wrote:
>> [Solution]
>>
>> To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
>> cpus at boot time, and make it invariable. 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.
>>
>> apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
>> MADT (Multiple APIC Description Table). So we finish the job in the following steps:
>>
>> 1. Enable apic registeration flow to handle both enabled and disabled cpus.
>> This is done by introducing an extra parameter to generic_processor_info to let the
>> caller control if disabled cpus are ignored.
>>
>> 2. Introduce a new array storing all possible cpuid <-> apicid mapping. And also modify
>> the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping when
>> registering local apic. Store the mapping in the array introduced above.
>>
>> 4. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus' apicid.
>> This is also done by introducing an extra parameter to these apis to let the caller
>> control if disabled cpus are ignored.
>>
>> 5. Establish all possible cpuid <-> nodeid mapping.
>> This is done via an additional acpi namespace walk for processors.
> Hmmm... given that we probably want to allocate lower ids to the
> online cpus, as otherwise we can end up failing to bring existing cpus
> online because NR_CPUS is lower than the number of possible cpus, I
> wonder whether doing this lazily could be better / easier. e.g. just
> remember the mapping as cpus come online. When a new cpu comes up,
> look up whether it came up before. If so, use the ids from the last
> time. If not, allocate new ones. I think that would be less amount
> of change but does require updating the mapping dynamically.
Hi TJ,
Allocating cpuid when a new cpu comes up and reusing the cpuid when it
comes up again is possible. But I'm not quite sure if it will be less
modification
because we still need an array or bit map or something to keep the mapping,
and select backup nodes for cpus on memory-less nodes when allocating
memory.
I can post a set of patches for this idea. And then we can see which one
is better.
Thanks. :)
--
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>
next prev parent reply other threads:[~2015-07-23 4:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 9:30 [PATCH 0/5] Make cpuid <-> nodeid mapping persistent Tang Chen
2015-07-07 9:30 ` [PATCH 1/5] x86, gfp: Cache best near node for memory allocation Tang Chen
2015-07-15 21:48 ` Tejun Heo
2015-08-04 3:36 ` Tang Chen
2015-08-04 8:05 ` Jiang Liu
2015-08-04 8:24 ` Tang Chen
2015-08-09 6:15 ` Tang Chen
2015-08-12 1:53 ` Jiang Liu
2015-08-04 8:26 ` gongzhaogang
2015-08-04 8:53 ` Tang Chen
2015-08-04 8:58 ` Tang Chen
2015-07-07 9:30 ` [PATCH 2/5] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus at boot time Tang Chen
2015-07-07 9:30 ` [PATCH 3/5] x86, acpi, cpu-hotplug: Introduce apicid_to_cpuid[] array to store persistent cpuid <-> apicid mapping Tang Chen
2015-07-07 11:14 ` Mika Penttilä
2015-07-15 3:33 ` Tang Chen
2015-07-15 5:35 ` Jiang Liu
2015-07-15 6:26 ` Tang Chen
2015-07-15 22:02 ` Tejun Heo
2015-07-07 9:30 ` [PATCH 4/5] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid Tang Chen
2015-07-15 22:06 ` Tejun Heo
2015-07-07 9:30 ` [PATCH 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting Tang Chen
2015-07-15 22:13 ` [PATCH 0/5] Make cpuid <-> nodeid mapping persistent Tejun Heo
2015-07-23 4:44 ` Tang Chen [this message]
2015-07-23 18:32 ` Tejun Heo
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=55B07145.5010404@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=gongzhaogang@inspur.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=qiaonuohan@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).