[PATCH] Implement support for mem command line parameter
vgoyal at redhat.com
Mon Jun 9 23:00:51 EDT 2008
On Mon, Jun 09, 2008 at 11:57:29PM +0200, Bernhard Walle wrote:
> * 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 22.214.171.124 (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.
Cool. Now atleast behavior across x86 and x86_64 is same.
> > 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
I think this interface might be acceptable to community. Lets write a
patch and present our case to community.
> Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
More information about the kexec