All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Mundt <lethal@linux-sh.org>
Cc: David Miller <davem@davemloft.net>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: numa aware lmb and sparc stuff
Date: Mon, 10 May 2010 15:29:23 +1000	[thread overview]
Message-ID: <1273469363.23699.26.camel@pasglop> (raw)
In-Reply-To: <20100510050158.GA24592@linux-sh.org>

On Mon, 2010-05-10 at 14:01 +0900, Paul Mundt wrote:
> On Mon, May 10, 2010 at 02:35:26PM +1000, Benjamin Herrenschmidt wrote:
> > So unless i'm missing something, I should be able to completely remove
> > lmb's reliance on that nid_range() callback and instead have lmb itself
> > use the various early_node_map[] accessors such as
> > for_each_active_range_index_in_nid() or similar.
> > 
> If you do this then you will also be coupling LMB with
> ARCH_POPULATES_NODE_MAP, which the nid_range() callback offers an
> alternative for (although since there aren't any architectures presently
> using LMB that don't also set ARCH_POPULATES_NODE_MAP perhaps this is
> ok). The nobootmem stuff also has a reliance on the early node map
> already.

Right, my tentative implementation indeed requires
ARCH_POPULATES_NODE_MAP for lmb_alloc_nid() to be available (I even
documented it). Do you see that as a limitation in the long run ?

> > If not, then I should be able to easily make that whole LMB numa thing
> > completely arch neutral.
> > 
> I've just started sorting out some of the LMB/NUMA bits on SH now as
> well, so I'd certainly be interested in any changes on top of Yinghai's
> work you're planning on doing.

I'm not sure I plan to change things on -top- of Yinghai work. I'm still
maintaining a patch series that is rooted before Yinghai current one, as
I very very much dislike pretty much everything in there. Though I plan
to provide all the functionality he needs for his x86 port and
NO_BOOTMEM implementation.

I'll post my WIP series later today after I got a chance to do some
tests.

Cheers,
Ben.


--
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:[~2010-05-10  5:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10  4:35 numa aware lmb and sparc stuff Benjamin Herrenschmidt
2010-05-10  5:01 ` Paul Mundt
2010-05-10  5:29   ` Benjamin Herrenschmidt [this message]
2010-05-10  6:03     ` Paul Mundt
2010-05-10  7:00       ` Benjamin Herrenschmidt
2010-05-10  7:49       ` Benjamin Herrenschmidt

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=1273469363.23699.26.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=lethal@linux-sh.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /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.