public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Robert Picco <Robert.Picco@hp.com>,
	Jesse Barnes <jbarnes@sgi.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matthew Dobson <colpatch@us.ibm.com>
Subject: Re: boot time node and memory limit options
Date: Wed, 17 Mar 2004 12:52:47 -0800	[thread overview]
Message-ID: <1079556766.5789.593.camel@nighthawk> (raw)
In-Reply-To: <2611830000.1079552673@[10.10.2.4]>

On Wed, 2004-03-17 at 11:44, Martin J. Bligh wrote:
> Yes ... that's looking very 2.7-ish to reorganise all that stuff.
> However, for now, I still think we need to restrict memory very early
> on, before anything else can allocate bootmem. Are you the absolute
> first thing that ever runs in the boot allocator?

I definitely agree with the 2.7 target for what I posted.  We can do it
cleanly in 2.7, but for now, I think the most best solution is to do it
in each architecture.  Partly because it's the way that we already do
mem=, plus I'm not sure the boot allocator code will work with all
architectures, at least ppc64.  

It's probably an oversight in the implementation (of the early ppc64
boot code), but there is some required correlation required with things
like lmb_end_of_DRAM() and how much memory is being used by the mm
structures.  I've played with it a bit, and I _think_ that you would be
required to modify the lmb structures, even with Robert's bootmem patch.

I could be wrong, so can somebody test it on a NUMA ppc64 machine?

Also, it may have been discussed before, but does the bootmem patch have
any applicability to the 32-bit NUMA platforms?  It looks like it just
deals with ZONE_DMA.

-- dave


  parent reply	other threads:[~2004-03-17 20:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4057392A.8000602@hp.com>
2004-03-16 17:43 ` boot time node and memory limit options Jesse Barnes
2004-03-16 19:39   ` Martin J. Bligh
2004-03-17 16:15     ` Robert Picco
2004-03-17 16:36       ` Martin J. Bligh
2004-03-17 17:09         ` Dave Hansen
2004-03-17 17:51           ` Jesse Barnes
2004-03-17 18:12             ` Dave Hansen
2004-03-17 19:30         ` Robert Picco
2004-03-17 19:44           ` Martin J. Bligh
2004-03-17 20:01             ` Robert Picco
2004-03-17 20:58               ` Martin J. Bligh
2004-03-17 20:52             ` Dave Hansen [this message]
2004-03-16 17:07 Robert Picco
2004-03-16 17:34 ` Randy.Dunlap
     [not found] ` <16471.48076.447058.132559@napali.hpl.hp.com>
2004-03-17 18:07   ` Robert Picco

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=1079556766.5789.593.camel@nighthawk \
    --to=haveblue@us.ibm.com \
    --cc=Robert.Picco@hp.com \
    --cc=colpatch@us.ibm.com \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.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