public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Dave Hansen <haveblue@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: kexec reboot code buffer
Date: 28 Jan 2003 00:24:54 -0700	[thread overview]
Message-ID: <m1n0ll68jd.fsf@frodo.biederman.org> (raw)
In-Reply-To: <203100000.1043705004@flay>

"Martin J. Bligh" <mbligh@aracnet.com> writes:

> >> The problem is that I have not figured out how to tell the memory
> >> allocator just what I need, 
> > <snip>
> >> I guess I would make the standard zones something like:
> >> /*
> >>  * ZONE_DMA	  < 16 MB	ISA DMA capable memory
> >>  * ZONE_NORMAL  16-896 MB	direct mapped by the kernel
> >>  * ZONE_PHYSMEM 896-4096 MB	memory that is accessible with the
> >>                               MMU disabled.
> >>  * ZONE_HIGHMEM > 4096MB      only page cache and user processes
> >>  */
> > 
> > I think this might be overkill.  ZONE_NORMAL gives you what you want,
> > and I don't think it's worth it to introduce a new one just for the
> > relatively short timespan where you have the new kernel loaded, but
> > haven't actually shut down.  I think a little comment next to the
> > allocation explaining this will be more than enough.
> > 
> > Martin, any ideas?
> 
> We talked about creating a new zone specifically for DMA32 (ie <4Gb)
> for other reasons, but it's not there as yet. 

Right.  And because of that I don't feel bad about asking for a zone
that ends at 4GB, as it is a fairly general need in the kernel, even
if the rest of the interfaces have a little catching up to do before
the can use it.  Although with IOMMUs I don't know how much such a
DMA32 zone is worth.

> As Dave mentioned,
> ZONE_NORMAL should be sufficient, though if you need it physically
> contiguous, that might be a problem.

I am fine with memory that is not physically contiguous.  The memory
I really want the kernel is currently sitting on.....

> How much memory do you need? If it's only 2Mb or so, why don't we
> statically reserve it at boot time and keep it set aside?

The largest I have heard of is currently is 96MB.   Typical is
somewhere between 900K and 6MB.  You get some interesting
kernel+ramdisk combinations when people are network booting a diskless
system.   Theoretically I can accommodate a nearly 4GB image, with the
current code structure. 

So the 4GB instead of 960MB limit, and not pesimizing the kernel for
the cases where the new image sits in ram for a while (kexec on panic)
is while I modified my code to use high memory.

The nasty case comes with highmemory when I am allocating memory on a
32GB NUMA box and am allocating memory on the wrong node.  In which
case my code needs to allocate 28GB before it starts getting the
memory it wants.

Eric

  parent reply	other threads:[~2003-01-28  7:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E31AC58.2020802@us.ibm.com>
2003-01-25 14:16 ` kexec reboot code buffer Eric W. Biederman
2003-01-27 21:55   ` Dave Hansen
2003-01-27 22:03     ` Martin J. Bligh
2003-01-28  0:10       ` William Lee Irwin III
2003-01-28  7:24       ` Eric W. Biederman [this message]
2003-01-28 16:15         ` Martin J. Bligh
2003-01-29 15:41           ` Eric W. Biederman
2003-01-29 16:17             ` Martin J. Bligh
2003-01-28  7:04     ` Eric W. Biederman
2003-01-28  7:18       ` William Lee Irwin III
2003-01-28  7:28         ` Eric W. Biederman
2003-01-28  7:31           ` William Lee Irwin III
2003-01-28 15:21             ` Eric W. Biederman

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=m1n0ll68jd.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.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