From: Dave Hansen <haveblue@us.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: KAMEZAWA Hiroyuki
<kamezawa.hiroyu.kamezawa.hiroyu@jp.fujitsu.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Hariprasad Nellitheertha [imap]" <hari@in.ibm.com>
Subject: Re: [RFC][PATCH] nameing reserved pages [0/3]
Date: Wed, 20 Apr 2005 10:00:36 -0700 [thread overview]
Message-ID: <1114016436.6927.9.camel@localhost> (raw)
In-Reply-To: <1114000447.6238.64.camel@laptopd505.fenrus.org>
On Wed, 2005-04-20 at 14:34 +0200, Arjan van de Ven wrote:
> On Wed, 2005-04-20 at 21:02 +0900, KAMEZAWA Hiroyuki wrote:
> > Hi,
> >
> > There are several types of PG_reserved pages,
> > (a) Memory Hole
> > (b) Used by Kernel
> > (c) Set by drivers
> > (d) Isorated by MCA
> > (e) used by perfmon
> > etc....
> >
> > I think it's useful to distinguish many types of PG_reserved pages.
>
> I'm not so sure about this. at all.
Neither am I, that's why I hoped somebody would figure out something
better :)
> > For example, Memory Hotplug can ignore (a).
>
> Memory Hotplug can also use page_is_ram().
It uses this, to some degree, internally. But, things like the e820
table don't get updated as memory hotplugs occur.
This should a way to give more fine-grained information about what pages
are availabe as RAM at any point in time. kdump would need something
like this to figure out which pages inside of /dev/mem are actually
valid to dump. Here was another approach that used /proc files:
http://lkml.org/lkml/2005/3/24/11
> /dev/memstate really looks like a bad idea to me as well... I rather
> have less than more /dev/*mem*
Any other ideas?
-- Dave
prev parent reply other threads:[~2005-04-20 18:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-20 12:02 [RFC][PATCH] nameing reserved pages [0/3] KAMEZAWA Hiroyuki
2005-04-20 12:34 ` Arjan van de Ven
2005-04-20 14:15 ` Kamezawa Hiroyuki
2005-04-20 14:30 ` Arjan van de Ven
2005-04-20 14:58 ` Kamezawa Hiroyuki
2005-04-20 17:18 ` Dave Hansen
2005-04-20 17:00 ` Dave Hansen [this message]
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=1114016436.6927.9.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=arjan@infradead.org \
--cc=hari@in.ibm.com \
--cc=kamezawa.hiroyu.kamezawa.hiroyu@jp.fujitsu.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.