From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Matt Mackall <mpm@selenic.com>
Cc: Paul Mundt <lethal@linux-sh.org>,
Christoph Lameter <clameter@sgi.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, ak@suse.de, hugh@veritas.com,
lee.schermerhorn@hp.com
Subject: Re: [PATCH] numa: mempolicy: dynamic interleave map for system init.
Date: Tue, 12 Jun 2007 12:36:58 +1000 [thread overview]
Message-ID: <466E06CA.9030302@yahoo.com.au> (raw)
In-Reply-To: <20070608145011.GE11115@waste.org>
Matt Mackall wrote:
> On Fri, Jun 08, 2007 at 12:25:05PM +0900, Paul Mundt wrote:
>
>>Well, this doesn't all have to be dynamic either. I opted for the
>>mpolinit= approach first so we wouldn't make the accounting for the
>>common case heavier, but certainly having it dynamic is less hassle. The
>>asymmetric case will likely be the common case for embedded, but it's
>>obviously possible to try to work that in to SLOB or something similar,
>>if making SLUB or SLAB lighterweight and more tunable for these cases
>>ends up being a real barrier.
>>
>>On the other hand, as we start having machines with multiple gigs of RAM
>>that are stashed in node 0 (with many smaller memories in other nodes),
>>SLOB isn't going to be a long-term option either.
>
>
> SLOB in -mm should scale to this size reasonably well now, and Nick
> and I have another tweak planned that should make it quite fast here.
Indeed. The existing code in -mm should hopefully get merged next cycle,
so if you have ever wanted to use SLOB but had performance problems, please
reevaluate and report if you still hit problems.
Even on small SMPs, it might be a reasonable choice, although it won't be
able to match the other allocators for performance. Again, if you have
problems with SMP scalability of SLOB, then please let us know too, because
as Matt said there are a few things we could do (such as multiple freelists)
which may improve performance quite a bit without hurting complexity or
memory usage much.
--
SUSE Labs, Novell Inc.
--
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:[~2007-06-12 2:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-07 1:17 [PATCH] numa: mempolicy: dynamic interleave map for system init Paul Mundt
2007-06-08 1:01 ` Andrew Morton
2007-06-08 2:47 ` Christoph Lameter
2007-06-08 3:01 ` Andrew Morton
2007-06-08 3:11 ` Christoph Lameter
2007-06-08 3:25 ` Paul Mundt
2007-06-08 3:49 ` Christoph Lameter
2007-06-08 4:13 ` Paul Mundt
2007-06-08 4:27 ` Christoph Lameter
2007-06-08 6:05 ` Paul Mundt
2007-06-08 6:09 ` Christoph Lameter
2007-06-08 6:27 ` Paul Mundt
2007-06-08 6:43 ` Christoph Lameter
2007-06-08 14:50 ` Matt Mackall
2007-06-12 2:36 ` Nick Piggin [this message]
2007-06-12 9:43 ` Paul Mundt
2007-06-12 15:32 ` Matt Mackall
2007-06-13 2:10 ` Nick Piggin
2007-06-13 3:12 ` Matt Mackall
2007-06-13 2:53 ` Paul Mundt
2007-06-13 3:16 ` Matt Mackall
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=466E06CA.9030302@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=lee.schermerhorn@hp.com \
--cc=lethal@linux-sh.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.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