lkml.org 
[lkml]   [2013]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86, kdump: Set crashkernel_low automatically
On Mon, Mar 11, 2013 at 12:04:38PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:02 PM, Vivek Goyal wrote:
> >>
> >> What is the purpose of reserving that kind of memory below 896 MB? If
> >> you have a 32-bit system, it will likely be useless since you are
> >> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> >> a magic value in any way...?
> >
> > Actually I am not sure where did 896MB magic value had come from for
> > x86_64 so far. I assumed that it was some kexec-tools limitation so
> > first trying 896MB will preserve working with old kexec-tools. If it
> > was some kernel limitation, then I agree it should not be required anymore.
> >
> > I do remember that old pugatory had 2G limit. So may be we can first
> > try reserve with-in first 2G, then with-in first 4G and then above
> > 4G. (Assuming 896M was not kexec-tools limitation and had something
> > to do with kernel/initramfs).
> >
>
> It is obvious where it *originated* from... it is the *default* (but not
> necessarily the actual!) HIGHMEM crossover point on x86-32.
>

On x86-32, max addr limit is 512M. 896M limit is on x86_64. So it probably
came from somewhere else.

Also always reserving at high memory cuts down on what kind of bzImage
can be booted from that address. For example, x86_32bit kernels. Hence
reserving at low addresses enables booting more type of images without
rebooting.

Thanks
Vivek


\
 
 \ /
  Last update: 2013-03-11 21:04    [W:2.138 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site