From: Christoph Lameter <clameter@sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: David Rientjes <rientjes@cs.washington.edu>,
akpm@osdl.org, linux-mm@kvack.org, nickpiggin@yahoo.com.au,
ak@suse.de, mbligh@google.com, rohitseth@google.com,
menage@google.com
Subject: Re: [RFC] memory page_alloc zonelist caching speedup
Date: Tue, 10 Oct 2006 10:07:36 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0610101001480.927@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20061010000331.bcc10007.pj@sgi.com>
Could it be worth to investigate more radical ideas? This gets way too
complicated for me. Maybe drop the whole zone list generation idea and
iterate over nodes in another way?
1. Have an allocator that is not node aware and can just deal with
memory in up to 3 different zones. No NUMA at all.
2. Have another NUMA allocator that uses the node unaware allocator
but implements its own way of handling the NUMA situation with proper
fallbacks etc etc. Maybe we could then merge the allocation logic
from mempolicy.c into the page allocator?
If 2 is generic enough then it can be used for other allocators as well
(like slab, hugepages, uncaches allocators) and provide a coherent
NUMA allocation handling for all allocators on NUMA.
It would be great if we could simplify and modularize the page allocator.
--
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>
next prev parent reply other threads:[~2006-10-10 17:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-09 10:54 [RFC] memory page alloc minor cleanups Paul Jackson, Paul Jackson
2006-10-09 10:54 ` [RFC] memory page_alloc zonelist caching speedup Paul Jackson
2006-10-09 18:12 ` Andrew Morton
2006-10-09 22:02 ` Paul Jackson
2006-10-10 4:51 ` Paul Jackson
2006-10-10 6:34 ` David Rientjes
2006-10-10 7:03 ` Paul Jackson
2006-10-10 17:07 ` Christoph Lameter [this message]
2006-10-10 19:35 ` Paul Jackson
2006-10-10 6:45 ` Paul Jackson
2006-10-09 11:08 ` [RFC] memory page alloc minor cleanups Christoph Lameter
2006-10-09 11:50 ` Paul Jackson
2006-10-09 17:12 ` Christoph Lameter
2006-10-09 13:11 ` Nick Piggin
2006-10-09 20:24 ` Paul Jackson
2006-10-10 1:45 ` Paul Jackson
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.0610101001480.927@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@google.com \
--cc=menage@google.com \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=rientjes@cs.washington.edu \
--cc=rohitseth@google.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