The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Anton Blanchard <anton@samba.org>
Cc: lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@muc.de>
Subject: [PATCH] NUMA-aware per-cpu allocation
Date: Fri, 04 Jun 2004 16:17:04 +1000	[thread overview]
Message-ID: <1086329823.7990.1101.camel@bach> (raw)

Stolen from x86_64: if we have NUMA, then use alloc_bootmem_node.

Can't hurt, I figure.

In 2.7, my cunning plan is to require contiguous sections, and allocate
similar sections for the dynamic per-cpu allocations, so this won't work
(archs will need to use tricks to create virtually-contiguous memory
from different NUMA nodes).  I have a bitrotted implementation.

Meanwhile, this compiles: does it help performance?

Name: Per-CPU Memory On Right Nodes
Status: Untested

Stolen from x86_64: for NUMA machines, allocate the per-cpu memory
using alloc_bootmem_node so it's optimally placed.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .1784-linux-2.6.7-rc2-bk4/include/asm-ppc64/percpu.h .1784-linux-2.6.7-rc2-bk4.updated/include/asm-ppc64/percpu.h
--- .1784-linux-2.6.7-rc2-bk4/include/asm-ppc64/percpu.h	2004-02-04 15:39:11.000000000 +1100
+++ .1784-linux-2.6.7-rc2-bk4.updated/include/asm-ppc64/percpu.h	2004-06-04 14:49:59.000000000 +1000
@@ -1,6 +1,8 @@
 #ifndef __ARCH_PPC64_PERCPU__
 #define __ARCH_PPC64_PERCPU__
 
+/* Big sloppy arch needs more per-cpu room than usual */
+#define PERCPU_ENOUGH_ROOM 65536
 #include <asm-generic/percpu.h>
 
 #endif /* __ARCH_PPC64_PERCPU__ */
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .1784-linux-2.6.7-rc2-bk4/init/main.c .1784-linux-2.6.7-rc2-bk4.updated/init/main.c
--- .1784-linux-2.6.7-rc2-bk4/init/main.c	2004-05-31 09:57:40.000000000 +1000
+++ .1784-linux-2.6.7-rc2-bk4.updated/init/main.c	2004-06-04 14:53:17.000000000 +1000
@@ -338,12 +338,26 @@ static void __init setup_per_cpu_areas(v
 		size = PERCPU_ENOUGH_ROOM;
 #endif
 
+	/* Multiple allocs for non-NUMA just wastes memory. */
+#ifdef CONFIG_NUMA
+	for (i = 0; i < NR_CPUS; i++) { 
+		pg_data_t *pgdat;
+
+		pgdat = NODE_DATA(cpu_to_node(i));
+		ptr = alloc_bootmem_node(pgdat, size);
+		if (!ptr)
+			panic("Cannot allocate cpu data for CPU %ld\n", i);
+		__per_cpu_offset[i] = ptr - __per_cpu_start;
+		memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
+	}
+#else
 	ptr = alloc_bootmem(size * NR_CPUS);
 
 	for (i = 0; i < NR_CPUS; i++, ptr += size) {
 		__per_cpu_offset[i] = ptr - __per_cpu_start;
 		memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
 	}
+#endif /* CONFIG_NUMA */
 }
 #endif /* !__GENERIC_PER_CPU */
 

-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell


                 reply	other threads:[~2004-06-04  6:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1086329823.7990.1101.camel@bach \
    --to=rusty@rustcorp.com.au \
    --cc=ak@muc.de \
    --cc=anton@samba.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