[lkml]   [2005]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC] Obtaining memory information for kexec/kdump

The topic of creating a common interface across
architectures for obtaining system RAM information has been
discussed on lkml and fastboot for a while now. Kexec needs
information about the entire physical RAM present in the
system while kdump needs information on the memory that the
kernel has booted with.

The /proc/iomem interface is insufficient because its
behavior varies across architectures.

- on i386, /proc/iomem reflects the memory that the system
has booted with. But, it does not reflect memory above 4GB.
- on x86_64, /proc/iomem reflects the entire physical memory
present irrespective of how much memory the kernel has
booted with.
- on ppc64, /proc/iomem does not reflect system RAM at all.

The patches that follow provide two views in the proc file
system so we have a common mechanism of extracting this

- A map of the entire physical memory present, irrespective
of whether the system has been booted with mem= or memmap=
options. This view comes up as /proc/physmem.

- A map of the memory currently used by the kernel. This map
can be accessed as /proc/activemem. This view will vary from
the previous one depending upon the values provided by mem=
or memmap= options.

Since the patches made use of the "resource" struct to store
and retrieve this information, some modifications were
needed to convert the "start" and "end" fields of struct
resource to u64. The first patch of the series makes this
conversion. The rest of the patches provide the code for the
two maps.

The patches are for the i386 and x86_64 architectures and
against 2.6.12-rc1-mm1.

Kindly review and comment on the patches.

Thanks and Regards, Hari
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:30    [W:0.063 / U:35.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site