mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Andi Kleen" <ak@suse.de>, "Andrew Morton" <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 3/3] x86_64: offset apicid_to_node before use it before init_cpu_to_node
Date: Sat, 21 Jul 2007 17:49:41 -0700	[thread overview]
Message-ID: <86802c440707211749x3258891fhbb72a155dc484e86@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

[PATCH 3/3] x86_64: offset apicid_to_node before use it before init_cpu_to_node

When acpi=off or there is no SRAT defined, apicid_to_node is got from K8
Northbridge PCI configuration space in k8_scan_nodes() in
arch/x86_64/mm/k8toplogy.c.
The problem is that it assumes bsp apic id is 0 at that point.
For four socket system with Quad core cpus installed, all cpus apic id
is offset by 4, and bsp apic id is 4.
For eight socket system with dual core cpus installed, all cpus apic id
is offset by 2, and bsp apic id is 2.
We need offset apicid_to_node array according to boot_cpu_id.--- bsp apic id.
before we use apicid_to_node array.
boot_cpu_id is only valid init_apic_mappings.

So do update_apicid_to_node and init_cpu_to_node after init_apic_mappings

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

 arch/x86_64/kernel/setup.c |   10 ++++++++--
 arch/x86_64/mm/numa.c      |   24 ++++++++++++++++++++++++
 include/asm-x86_64/numa.h  |    2 ++
 3 files changed, 34 insertions(+), 2 deletions(-)

[-- Attachment #2: 3.patch --]
[-- Type: text/x-patch, Size: 2249 bytes --]


diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index 33ef718..1862a91 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -385,8 +385,6 @@ void __init setup_arch(char **cmdline_p)
 	acpi_boot_init();
 #endif
 
-	init_cpu_to_node();
-
 	/*
 	 * get boot-time SMP configuration:
 	 */
@@ -395,6 +393,14 @@ void __init setup_arch(char **cmdline_p)
 	init_apic_mappings();
 
 	/*
+	 * need to put init_cpu_to_node after init_apic_mappings
+	 * we need to get boot_cpu_id (the BSP apic id) to modify
+	 * apicid_to_node array, before init_cpu_node
+	 */
+	update_apicid_to_node();
+	init_cpu_to_node();
+
+	/*
 	 * We trust e820 completely. No explicit ROM probing in memory.
  	 */
 	e820_reserve_resources(); 
diff --git a/arch/x86_64/mm/numa.c b/arch/x86_64/mm/numa.c
index 5154894..91605aa 100644
--- a/arch/x86_64/mm/numa.c
+++ b/arch/x86_64/mm/numa.c
@@ -607,6 +607,30 @@ early_param("numa", numa_setup);
  * prior to this call, and this initialization is good enough
  * for the fake NUMA cases.
  */
+void __init update_apicid_to_node(void)
+{
+	/*
+	 * let modify apicid_to_node array when boot_cpu_id !=0
+	 * apicid_to_node[0] != NUMA_NODE
+	 */
+
+	int i;
+
+	/* there is no apic id offset */
+	if (!boot_cpu_id)
+		return;
+
+	/* check if it is already updated */
+	if (apicid_to_node[0] == NUMA_NO_NODE)
+		return;
+
+	for (i = NR_CPUS -1; i >= boot_cpu_id; i--)
+		apicid_to_node[i] = apicid_to_node[i - boot_cpu_id];
+
+	for (i = boot_cpu_id - 1; i >= 0; i--)
+		apicid_to_node[i] = NUMA_NO_NODE;
+
+}
 void __init init_cpu_to_node(void)
 {
 	int i;
diff --git a/include/asm-x86_64/numa.h b/include/asm-x86_64/numa.h
index 933ff11..282b7a7 100644
--- a/include/asm-x86_64/numa.h
+++ b/include/asm-x86_64/numa.h
@@ -21,6 +21,7 @@ extern int hotadd_percent;
 
 extern unsigned char apicid_to_node[256];
 #ifdef CONFIG_NUMA
+extern void __init update_apicid_to_node(void);
 extern void __init init_cpu_to_node(void);
 
 static inline void clear_node_cpumask(int cpu)
@@ -29,6 +30,7 @@ static inline void clear_node_cpumask(int cpu)
 }
 
 #else
+#define update_apicid_to_node() do {} while (0)
 #define init_cpu_to_node() do {} while (0)
 #define clear_node_cpumask(cpu) do {} while (0)
 #endif

             reply	other threads:[~2007-07-22  0:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-22  0:49 Yinghai Lu [this message]
2007-07-22  8:05 ` David Rientjes
2007-07-22  8:17   ` Yinghai Lu
2007-07-22 12:52 ` Andi Kleen
2007-07-22 22:54   ` Yinghai Lu
2007-07-23  0:29     ` Andi Kleen

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=86802c440707211749x3258891fhbb72a155dc484e86@mail.gmail.com \
    --to=yhlu.kernel@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®