From: Christoph Lameter <christoph@engr.sgi.com>
To: linux-mm@vger.kernel.org
Cc: ak@suse.de, akpm@osdl.org, pj@sgi.com
Subject: A radical idea on how to solve various VM problems
Date: Sat, 16 Sep 2006 12:21:16 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0609161210190.12677@schroedinger.engr.sgi.com> (raw)
Ummm... Since we are using nodes for containers now how about
generalizing that and use such a node container for ZONE_DMA, ZONE_DMA32
and ZONE_HIGHMEM?
In that case we will then have only one zone per node which simplifies the
VM and allows optimizations in various kernel subsystems. (Note that AFAIK
all NUMA systems have only a single zone in nodes > 0 anyways, the
overhead for more zones is mostly unnecessary).
In that case also all system are "NUMA" systems (solving the #ifdef
CONFIG_NUMA mess). We could give the special memory zones negative
indexes.
F.e. a i386 UP/SMP system
-2 DMA "node"
-1 Normal "node"
0 Highmem "node"
A x86_64 UP/SMP system
-2 DMA "node"
-1 DMA32 "node"
0 Norma "node"
We can then add more nodes on top to get our containers and more nodes to
the bottom to get more special allocation areas that we may need for some
hardware. These could be added dynamically via node up node down
functionality that already exists. So if we discover a strange DMA device
or broken DMA device with limited address range we could custom add a zone
(no "node") that would satisfy that requirement.
The NUMA systems then become more nodes
i386 32 BIT NUMA
-2 DMA
-1 NORMAL
0 HIGHMEM of node 0
1 HIGHMEM of node 1
....
64 bit numa system with legacy allocation requirements
-2 DMA
-1 DMA32
0 NORMAL of node 0
1 NORMAL of node 1
2 NORMAL of node 2
...
Pure 64 bit NUMA system (no special memory pools for
legacy DMA)
0 NORMAL of node 0
1 NORMAL of node 1
...
This also benefits the slab allocator. There is no need anymore for
special DMA slabs. A GFP_DMA allocation is the same as a kmalloc_node
allocation from the DMA "node".
--
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>
reply other threads:[~2006-09-16 19:27 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=Pine.LNX.4.64.0609161210190.12677@schroedinger.engr.sgi.com \
--to=christoph@engr.sgi.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-mm@vger.kernel.org \
--cc=pj@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