linux-mm.kvack.org archive mirror
 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 17:49:17 +1000	[thread overview]
Message-ID: <1273477757.23699.84.camel@pasglop> (raw)
In-Reply-To: <20100510060316.GA12250@linux-sh.org>


> I wouldn't call it a limitation so much as a subtle dependency. All of
> the current platforms that are supporting NUMA are doing so along with
> ARCH_POPULATES_NODE_MAP, so in those cases making the early_node_map
> dependence explicit and generic will permit the killing off of
> architecture-private data structures and accounting for region sizes and
> node mappings.
> 
> The NUMA platforms that do not currently follow the
> ARCH_POPULATES_NODE_MAP semantics seem to already be in various states of
> disarray (generically broken, bitrotted, etc.). To that extent, perhaps
> it's also useful to have NUMA imply ARCH_POPULATES_NODE_MAP? New
> architectures that are going to opt for sparsemem or NUMA are likely
> going to end up down the ARCH_POPULATES_NODE_MAP path anyways I would
> imagine.

Ok so I had a chat with Dave and it looks like that won't do for sparc. 

They don't really have ranges. Or rather, they do in HW, but with their
hypervisor, you can get the pages all scattered in what they call "real
memory", so early_node_map[] doesn't work well.

So I'll rollback my changes in that area for now, put back the arch
callback, but I'll keep at hand a default variant that uses
early_node_map[] for the like of us.

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>

      parent reply	other threads:[~2010-05-10  7:49 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
2010-05-10  6:03     ` Paul Mundt
2010-05-10  7:00       ` Benjamin Herrenschmidt
2010-05-10  7:49       ` Benjamin Herrenschmidt [this message]

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=1273477757.23699.84.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).