From: Hariprasad Nellitheertha <hari@in.ibm.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
fastboot <fastboot@lists.osdl.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@osdl.org>
Subject: [RFC] Obtaining memory information for kexec/kdump
Date: Thu, 24 Mar 2005 11:19:20 +0530 [thread overview]
Message-ID: <424254E0.6060003@in.ibm.com> (raw)
Hi,
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
information.
- 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
next reply other threads:[~2005-03-24 5:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 5:49 Hariprasad Nellitheertha [this message]
2005-03-24 5:52 ` [RFC][PATCH 1/7] Converting resource struct fields to 64 bit Hariprasad Nellitheertha
2005-03-24 5:53 ` [RFC][PATCH 2/7] Common code for the physmem map Hariprasad Nellitheertha
2005-03-24 5:55 ` [RFC][PATCH 3/7] i386 " Hariprasad Nellitheertha
2005-03-24 5:56 ` [RFC][PATCH 4/7] x86_64 " Hariprasad Nellitheertha
2005-03-24 5:57 ` [RFC][PATCH 5/7] Common code for the activemem map Hariprasad Nellitheertha
2005-03-24 5:58 ` [RFC][PATCH 6/7] i386 " Hariprasad Nellitheertha
2005-03-24 6:00 ` [RFC][PATCH 7/7] x86_64 " Hariprasad Nellitheertha
2005-03-24 7:50 ` [RFC] Obtaining memory information for kexec/kdump Dave Hansen
2005-03-24 10:19 ` Hariprasad Nellitheertha
2005-03-24 15:32 ` Dave Hansen
2005-03-28 13:00 ` Hariprasad Nellitheertha
2005-03-28 16:18 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=424254E0.6060003@in.ibm.com \
--to=hari@in.ibm.com \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox