linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Anton Blanchard <anton@samba.org>
Cc: Andrew Morton <akpm@digeo.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.68-mm4
Date: 03 May 2003 08:12:11 -0600	[thread overview]
Message-ID: <m1el3gce6c.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20030502153525.GA11939@krispykreme>

Anton Blanchard <anton@samba.org> writes:

> Hi,
> 
> > . Included the `kexec' patch - load Linux from Linux.  Various people want
> >   this for various reasons.  I like the idea of going from a login prompt to
> >   "Calibrating delay loop" in 0.5 seconds.
> 
> One thing that bothers me about kexec is how we grab low pages in
> kimage_alloc_page(). On a partitioned ppc64 box I will need to grab
> memory in the low 256MB and the machine might have 500GB of memory
> free. Thats going to take some time :)

Could you explain to me the need to allocate memory in the low 256MB.
Generally the design is that you can allocate the memory anywhere
and then relocate_kernel.S will move where it needs to be kept.

I have had people wanting to use 300MB initial ramdisks and the like.  
If you have 500GB of memory what is the point of keeping anything on a disk?

When you have 4TB on a cluster or a NUMA machine I can understand
wanting to keep things local to a node.  But in those cases you want
to have local node zones so the problem does not come up.

In general I hate restricting the memory you can use, because kexec is
not just about booting linux.  But it is about booting anything that
we reasonably can.  The only case I have seen so far that makes sense
is when your physical memory is larger than your virtual memory.

> Id hate to introduce a separate zone just for this sort of stuff (we
> currently throw all memory in the DMA zone). Could we add a hint to
> the page allocator where it makes a best effort to grab memory below
> a threshold?

I suspect so.  And I can't imagine it would be that hard to implement.

But I think I would like to see why you need that.

Eric

  reply	other threads:[~2003-05-03 14:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-02  9:01 2.5.68-mm4 Andrew Morton
2003-05-02 13:18 ` 2.5.68-mm4 William Lee Irwin III
2003-05-02 16:47   ` 2.5.68-mm4 Dave Hansen
2003-05-02 14:45 ` 2.5.68-mm4 Steven Cole
2003-05-02 15:00   ` 2.5.68-mm4 Steven Cole
2003-05-02 15:35 ` 2.5.68-mm4 Anton Blanchard
2003-05-03 14:12   ` Eric W. Biederman [this message]
2003-05-02 16:54 ` 2.5.68-mm4 Martin J. Bligh
2003-05-02 20:04 ` 2.5.68-mm4 Steven Cole
2003-05-02 20:34   ` 2.5.68-mm4 Andrew Morton
2003-05-02 20:49     ` 2.5.68-mm4 Steven Cole
2003-05-02 21:01       ` 2.5.68-mm4 Steven Cole
2003-05-02 21:05       ` 2.5.68-mm4 Andrew Morton
2003-05-02 21:20         ` 2.5.68-mm4 Steven Cole
2003-05-02 21:49           ` 2.5.68-mm4 Andy Pfiffer
2003-05-02 22:00             ` 2.5.68-mm4 Steven Cole
2003-05-02 23:22           ` 2.5.68-mm4 Matt Bernstein
2003-05-02 23:41             ` 2.5.68-mm4 Andrew Morton
2003-05-03  2:53               ` 2.5.68-mm4 Andi Kleen
2003-05-03  7:08                 ` 2.5.68-mm4 Matt Bernstein
     [not found]                   ` <Pine.LNX.4.55.0305061511020.3237@r2-pc.dcs.qmul.ac.uk>
2003-05-06 14:35                     ` 2.5.68-mm4 Andi Kleen
2003-05-06 15:50                       ` 2.5.68-mm4 Matt Bernstein
2003-05-07 10:27                       ` 2.5.68-mm4 Matt Bernstein
2003-05-07 12:35                         ` 2.5.68-mm4 Andi Kleen
2003-05-07 15:45                           ` 2.5.68-mm4 Matt Bernstein
2003-05-03  3:14               ` 2.5.68-mm4 Andi Kleen
2003-05-03 13:51               ` 2.5.68-mm4 Diego Calleja García
2003-05-03  1:14     ` 2.5.68-mm4 Herbert Xu
2003-05-05  3:46 ` 2.5.68-mm4 && kexec Eric W. Biederman
2003-05-02 19:58 2.5.68-mm4 J. Hidding
2003-05-03 11:52 2.5.68-mm4 cb-lkml

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=m1el3gce6c.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@digeo.com \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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).