Question re: mem= usage and resultant vmcore

Vivek Goyal vgoyal at
Thu Aug 2 00:46:53 EDT 2007

On Wed, Aug 01, 2007 at 12:29:59PM -0400, Dave Anderson wrote:
> On an 4GB x86_64 kernel, with memory restricted with "mem=" like so:
>    kernel /vmlinuz-2.6.18-36.el5 ro root=/dev/VolGroup00/LogVol00
>    console=ttyS0,115200 mem=2000m crashkernel=128M at 16M
> The secondary kernel boots fine with this:
>    Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0,115200
>    mem=2000m  irqpoll maxcpus=1 memmap=exactmap memmap=640K at 0K
>    memmap=5048K at 16384K memmap=125368K at 22072K elfcorehdr=147440K
>    memmap=76K#3406720K memmap=564K#3406796K
> The /proc/vmcore shows 4GB:
>    # ls -l /proc/vmcore
>    -r-------- 1 root root 4164192032 Aug  1 10:57 /proc/vmcore
>    #
> I'm not sure whether that's supposed to reflect the "mem=2000m" size
> or not?

Hi Dave,

/proc/iomem on i386 and x86_64 behave differently when passed with mem=
parameter. I think on i386, only memory specified by mem= is visible but
in case of x86_64, all the memory passed by BIOS to kernel is visible.

Kexec/kdump retrieve the physical memory info from /proc/iomem. We need
both the behaviours for two scenarios.

- For kexec, we want to see whole of the memory (irrespective of the fact
  how much current kernel is using), so that next kernel can potentially
  use all the memory to boot in.

- For kdump, we want to know about only the physical memory current kernel
  is using and not all the memory system has.

Here the issue is that despite the fact you have passed mem=2000m, /proc/iomem
will show 4G physical memory and kdump will create elf header for 4G of 
memory. That's why /proc/vmcore size is 4G. I am not sure why it did not
copy whole 4G on disk and stoppped after 2000m. To me it should have copied
whole of the 4G.

Bottom line, we need to do some work in this area.

- Make /proc/iomem behaviour consistent across i386 and x86_64. I think
  it can be changed to reflect the physical memory currently used by 
  kernel (based on mem=) parameter.

- Create another /proc interface, lets say /proc/physmem, which will reflect
  all the physical memory system has, irrespective of the fact what is being
  used by the kernel.

In this case kexec can make use of /proc/physmem and kdump can make use
of /proc/iomem and things will be fine.

Anybody interested in writing patches for this?


More information about the kexec mailing list