[PATCH] Implement support for mem command line parameter

Bernhard Walle bwalle at suse.de
Mon Jun 9 17:57:29 EDT 2008

* Vivek Goyal <vgoyal at redhat.com> [2008-06-02 23:04]:
> On Tue, Jun 03, 2008 at 01:29:44AM +0200, Bernhard Walle wrote:
> > When the kernel is booted with the "mem" kernel command line (see
> > Documentation/kernel-parameters.txt of kernel source tree), the /proc/iomem
> > is not modified. Instead, it shows the whole memory space as "System RAM".
> > I consider that as correct because the file is named "iomem", and for I/O,
> > the behaviour makes sense.
> > 
> IIUC, in the past the behavior of /proc/iomem was different for i386 and
> x86_64. One arch used to truncate it and other would not. I don't remember
> which one used to do what.

Right. I just checked with (openSUSE 10.3 kernel), and

  - i386: /proc/iomem contains full memory
  - x86_64: /proc/iomem contains truncated memory

After the x86 merge, x86_64 now has the behaviour of i386.

> I had a quick look at the current code and looks like truncation of e820
> map is taking place before request_resource(). In that case we should
> see the truncated map. But I am not sure and will test it tomorrow...

2.6.25 shows the full /proc/iomem.

> We probably will not touch /proc/iomem. We need to create a new interface
> which will change based on user options. That should not break any 
> user space applications?

That would make sense. I will prepare a patch tomorrow, I hope such a
interface will be accepted. One might argue that "just don't use mem,
it's only for debugging" or something.

> >  - We should not add yet another interface between kernel and userspace for
> >    a feature 99 % of the people don't need and don't even know about.
> > 
> > The semantics of mem is different on different architectures. i386 and x86_64
> > (x86) treat the limit specified on the command line as physical address limit
> You mean system RAM limit? Because PCI devices are still mapped at higher
> physical addresses. So it is not physical address limit?

In x86 the mem=3G means that the highest RAM memory address is
3*1024*1024*1024 bytes physical address space. Removing the hole
between 640K and 1M and 15M and 16M, that's not exactly 3G memory.

> > while IA64 count the real memory. That is because of different practises of
> > memory mapping on PC architecture vs. "new" architectures.

And IA64 really counts that memory, so 'free -m' will show 3*1024 in
that case.

> Hence I feel that we need to create two views. /proc/iomem can serve
> as unmodied io resource view as reported by BIOS, and /proc/iomem_used
> can serve as modified view as seen by kernel (due to user options.)

Right, that's the more *clean* solution, but it needs a new kernel

Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance

More information about the kexec mailing list