linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: 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, Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] numa: mempolicy: dynamic interleave map for system init.
Date: Fri, 8 Jun 2007 09:50:11 -0500	[thread overview]
Message-ID: <20070608145011.GE11115@waste.org> (raw)
In-Reply-To: <20070608032505.GA13227@linux-sh.org>

On Fri, Jun 08, 2007 at 12:25:05PM +0900, Paul Mundt wrote:
> On Thu, Jun 07, 2007 at 07:47:09PM -0700, Christoph Lameter wrote:
> > On Thu, 7 Jun 2007, Andrew Morton wrote:
> > 
> > > Well I took silence as assent.
> > 
> > Well, grudgingly. How far are we willing to go to support these asymmetric 
> > setups? The NUMA code initially was designed for mostly symmetric systems 
> > with roughly the same amount of memory on each node. The farther we go 
> > from this the more options we will have to add special casing to deal with 
> > these imbalances.
> > 
> 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.

SLOB's big scalability problem at this point is number of CPUs.
Throwing some fine-grained locking at it or the like may be able to
help with that too.

Why would you even want to bother making it scale that large? For
starters, it's less affected by things like dcache fragmentation. The
majority of pages pinned by long-lived dcache entries will still be
available to other allocations.

Haven't given any thought to NUMA yet though..

-- 
Mathematics is the supreme nostalgia of our time.

--
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>

  parent reply	other threads:[~2007-06-08 14:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-07  1:17 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 [this message]
2007-06-12  2:36         ` Nick Piggin
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=20070608145011.GE11115@waste.org \
    --to=mpm@selenic.com \
    --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=nickpiggin@yahoo.com.au \
    /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