From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Christoph Lameter <clameter@engr.sgi.com>,
Dave Hansen <haveblue@us.ibm.com>,
Andy Whitcroft <apw@shadowen.org>
Cc: 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: Mon, 16 May 2005 11:08:35 -0700 [thread overview]
Message-ID: <714210000.1116266915@flay> (raw)
In-Reply-To: <Pine.LNX.4.62.0505161046430.1653@schroedinger.engr.sgi.com>
>> > How do the concepts of numa node id relate to discontig node ids?
>>
>> I believe there are quite a few assumptions on some architectures that,
>> when NUMA is on, they are equivalent. It appears to be pretty much
>> assumed everywhere that CONFIG_NUMA=y means one pg_data_t per NUMA node.
>
> Ah. That sounds much better.
>
>> Remember, as you saw, you can't assume that MAX_NUMNODES=1 when NUMA=n
>> because of the DISCONTIG=y case.
>
> I have never seen such a machine. A SMP machine with multiple
> "nodes"? So essentially one NUMA node has multiple discontig "nodes"?
I believe you (SGI) make one ;-) Anywhere where you have large gaps in
the physical address range within a node, this is what you really need.
Except ia64 has this wierd virtual mem_map thing that can go away once
we have sparsemem.
> This means that the concept of a node suddenly changes if there is just
> one numa node(CONFIG_NUMA off implies one numa node)?
The end point of where we're getting to is 1 node = 1 pgdat (which we can
then rename to struct node or something). All this confusing mess of
config options is just a migration path, which I'll leave it to Andy to
explain ;-)
> s/CONFIG_NUMA/CONFIG_NEED_MULTIPLE_NODES?
>
> That will not work because the idea is the localize the slabs to each
> node.
>
> If there are multiple nodes per numa node then invariable one node in the
> numa node (sorry for this duplication of what node means but I did not
> do it) must be preferred since numa_node_id() does not return a set of
> discontig nodes.
>
> Sorry but this all sounds like an flaw in the design. There is no
> consistent notion of node. Are you sure that this is not a ppc64 screwup?
No, it's a discontigmem screwup. Currently a pgdat represents 2 different
scenarios:
(1) physically discontiguous memory chunk.
(2) a NUMA node.
I don't think we support both at the same time with the old code. So it
seems to me like your numa aware slab code (which I'm still intending to
go read, but haven't yet) is only interested in real nodes. Logically
speaking, that would be CONFIG_NUMA. The current transition config options
are a bit of a mess ... Andy, I presume CONFIG_NEED_MULTIPLE_NODES is
really CONFIG_NEED_MULTIPLE_PGDATS ?
M.
--
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-16 18:08 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 [this message]
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
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=714210000.1116266915@flay \
--to=mbligh@mbligh.org \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=clameter@engr.sgi.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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