From: Matthew Dobson <colpatch@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Christoph Lameter <christoph@lameter.com>,
"Martin J. Bligh" <mbligh@mbligh.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Christoph Lameter <clameter@engr.sgi.com>,
Andy Whitcroft <apw@shadowen.org>, Andrew Morton <akpm@osdl.org>,
linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
shai@scalex86.org, steiner@sgi.com
Subject: Re: NUMA aware slab allocator V3
Date: Tue, 17 May 2005 16:36:45 -0700 [thread overview]
Message-ID: <428A800D.8050902@us.ibm.com> (raw)
In-Reply-To: <1116289613.26955.14.camel@localhost>
Dave Hansen wrote:
>>+#ifdef CONFIG_NUMA
>>+#define NUMA_NODES MAX_NUMNODES
>>+#define NUMA_NODE_ID numa_node_id()
>>+#else
>>+#define NUMA_NODES 1
>>+#define NUMA_NODE_ID 0
>> #endif
>
>
> I think numa_node_id() should always do what you want. It is never
> related to discontig nodes, and #defines down to the same thing you have
> in the end, anyway:
>
> #define numa_node_id() (cpu_to_node(_smp_processor_id()))
>
> asm-i386/topology.h
> #ifdef CONFIG_NUMA
> ...
> static inline int cpu_to_node(int cpu)
> {
> return cpu_2_node[cpu];
> }
>
> asm-generic/topology.h:
> #ifndef cpu_to_node
> #define cpu_to_node(cpu) (0)
> #endif
>
> As for the MAX_NUMNODES, I'd just continue to use it, instead of a new
> #define. There is no case where there can be more NUMA nodes than
> DISCONTIG nodes, and this assumption appears in plenty of other code.
>
> I'm cc'ing Matt Dobson, who's touched this MAX_NUMNODES business a lot
> more recently than I.
>
> -- Dave
You're right, Dave. The series of #defines at the top resolve to the same
thing as numa_node_id(). Adding the above #defines will serve only to
obfuscate the code.
Another thing that will really help, Christoph, would be replacing all your
open-coded for (i = 0; i < MAX_NUMNODES/NR_CPUS; i++) loops. We have
macros that make that all nice and clean and (should?) do the right thing
for various combinations of SMP/DISCONTIG/NUMA/etc. Use those and if they
DON'T do the right thing, please let me know and we'll fix them ASAP.
for_each_cpu(i)
for_each_online_cpu(i)
for_each_node(i)
for_each_online_node(i)
Those 4 macros should replace all your open-coded loops, Christoph.
-Matt
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-05-17 23:36 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-11 15:17 NUMA aware slab allocator V2 Christoph Lameter
2005-05-11 15:46 ` Jack Steiner
2005-05-12 7:04 ` Andrew Morton
2005-05-12 9:39 ` Niraj kumar
2005-05-12 20:02 ` Christoph Lameter
2005-05-12 20:22 ` Andrew Morton
2005-05-13 7:06 ` Andrew Morton
2005-05-13 11:21 ` Christoph Lameter
2005-05-13 11:33 ` Andrew Morton
2005-05-13 11:37 ` Christoph Lameter
2005-05-13 13:56 ` Dave Hansen
2005-05-13 16:20 ` Christoph Lameter
2005-05-14 1:24 ` NUMA aware slab allocator V3 Christoph Lameter
2005-05-14 7:42 ` Andrew Morton
2005-05-14 16:24 ` Christoph Lameter
2005-05-16 5:00 ` Andrew Morton
2005-05-16 13:52 ` Dave Hansen
2005-05-16 16:47 ` Christoph Lameter
2005-05-16 17:22 ` Dave Hansen
2005-05-16 17:54 ` Christoph Lameter
2005-05-16 18:08 ` Martin J. Bligh
2005-05-16 21:10 ` Jesse Barnes
2005-05-16 21:21 ` Martin J. Bligh
2005-05-17 0:14 ` Christoph Lameter
2005-05-17 0:26 ` Dave Hansen
2005-05-17 23:36 ` Matthew Dobson [this message]
2005-05-17 23:49 ` Christoph Lameter
2005-05-18 17:27 ` Matthew Dobson
2005-05-18 17:48 ` Christoph Lameter
2005-05-18 21:15 ` Matthew Dobson
2005-05-18 21:40 ` Christoph Lameter
2005-05-19 5:07 ` Christoph Lameter
2005-05-19 16:14 ` Jesse Barnes
2005-05-19 19:03 ` Matthew Dobson
2005-05-19 21:46 ` Matthew Dobson
2005-05-20 19:03 ` Matthew Dobson
2005-05-20 19:23 ` Christoph Lameter
2005-05-20 20:20 ` Matthew Dobson
2005-05-20 21:30 ` Matthew Dobson
2005-05-20 23:42 ` Christoph Lameter
2005-05-24 21:37 ` Christoph Lameter
2005-05-24 23:02 ` Matthew Dobson
2005-05-25 5:21 ` Christoph Lameter
2005-05-25 18:27 ` Matthew Dobson
2005-05-25 21:03 ` Christoph Lameter
2005-05-26 6:48 ` Martin J. Bligh
2005-05-28 1:59 ` NUMA aware slab allocator V4 Christoph Lameter
2005-05-16 21:54 ` NUMA aware slab allocator V3 Dave Hansen
2005-05-16 18:12 ` Dave Hansen
2005-05-13 13:46 ` NUMA aware slab allocator V2 Dave Hansen
2005-05-17 23:29 ` Matthew Dobson
2005-05-18 1:07 ` Christoph Lameter
2005-05-12 21:49 ` Robin Holt
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=428A800D.8050902@us.ibm.com \
--to=colpatch@us.ibm.com \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=christoph@lameter.com \
--cc=clameter@engr.sgi.com \
--cc=haveblue@us.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@mbligh.org \
--cc=shai@scalex86.org \
--cc=steiner@sgi.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