From: Paul Mundt <lethal@linux-sh.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Matt Mackall <mpm@selenic.com>,
Christoph Lameter <clameter@sgi.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] slob: poor man's NUMA, take 2.
Date: Wed, 13 Jun 2007 12:33:06 +0900 [thread overview]
Message-ID: <20070613033306.GA15169@linux-sh.org> (raw)
In-Reply-To: <466F6351.9040503@yahoo.com.au>
On Wed, Jun 13, 2007 at 01:24:01PM +1000, Nick Piggin wrote:
> Paul Mundt wrote:
> >Here's an updated copy of the patch adding simple NUMA support to SLOB,
> >against the current -mm version of SLOB this time.
> >
> >I've tried to address all of the comments on the initial version so far,
> >but there's obviously still room for improvement.
> >
> >This approach is not terribly scalable in that we still end up using a
> >global freelist (and a global spinlock!) across all nodes, making the
> >partial free page lookup rather expensive. The next step after this will
> >be moving towards split freelists with finer grained locking.
>
> I just think that this is not really a good intermediate step because
> you only get NUMA awareness from the first allocation out of a page. I
> guess that's an easy no-brainer for bigblock allocations, but for SLUB
> proper, it seems not so good.
>
> For a lot of workloads you will have a steady state where allocation and
> freeing rates match pretty well and there won't be much movement of pages
> in and out of the allocator. In this case it will be back to random
> allocations, won't it?
>
That's why I tossed in the node id matching in slob_alloc() for the
partial free page lookup. At the moment the logic obviously won't scale,
since we end up scanning the entire freelist looking for a page that
matches the node specifier. If we don't find one, we could rescan and
just grab a block from another node, but at the moment it just continues
on and tries to fetch a new page for the specified node.
If the freelists are split per node, that makes it a bit more manageable,
but that's more of a scalability issue than a correctness one. Random
alloc/free workloads will stick to their node with the current patch, so
I'm not sure where you see the random node placement as an issue?
--
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-13 3:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 3:12 [PATCH] slob: poor man's NUMA, take 2 Paul Mundt
2007-06-13 3:24 ` Nick Piggin
2007-06-13 3:32 ` Matt Mackall
2007-06-13 3:33 ` Paul Mundt [this message]
2007-06-13 3:39 ` Nick Piggin
2007-06-13 3:42 ` Nick Piggin
2007-06-13 4:13 ` Paul Mundt
2007-06-13 4:23 ` Paul Mundt
2007-06-13 5:30 ` Christoph Lameter
2007-06-13 5:42 ` Matt Mackall
2007-06-13 6:44 ` Nick Piggin
2007-06-13 9:50 ` Paul Mundt
2007-06-13 3:28 ` Matt Mackall
2007-06-13 9:21 ` Paul Mundt
2007-06-13 13:15 ` Matt Mackall
2007-06-13 22:47 ` Christoph Lameter
2007-06-14 2:43 ` Paul Mundt
2007-06-14 6:01 ` Christoph Lameter
2007-06-14 2:40 ` Paul Mundt
2007-06-14 6:00 ` Christoph Lameter
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=20070613033306.GA15169@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.