* 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 2.6.22.5 (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 interface. Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Maintenance
