From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch 0/6] remove PageReserved
Date: Wed, 27 Jul 2005 10:22:58 +1000 [thread overview]
Message-ID: <42E6D3E2.3050601@yahoo.com.au> (raw)
In-Reply-To: <9AB335F0-28CD-4561-B447-DA09CF44F0AB@freescale.com>
Kumar Gala wrote:
>>
>> Most of the arch code is just reserved memory reporting, which
>> isn't very interesting and could easily be removed. Some arch users
>> are a bit more subtle, however they *should not* break, because all
>> the places that set and clear PageReserved are basically intact.
>
>
> What is the desired fix look like for arch users?
>
It really depends on how it is used.
Firstly, we want to retain all the places that do SetPageReserved and
ClearPageReserved to ensure that remaining places that test PageReserved
will continue to work.
So users of PageReserved need to be removed. For example, on i386 this
is simply reserved memory accounting - which isn't very meaningful and
can probably be simply deleted. i386 ioremap also tests PageReserved to
ensure it isn't remapping usable RAM, which is a similar need to swsusp's,
so one solution would likely cover that ioremap and swsusp.
For now, the main thing to keep in mind is to not add a new user of
PageReserved. We can start looking at how to cut down existing users when
the core patch gets into -mm or further upstream.
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
prev parent reply other threads:[~2005-07-27 0:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-26 8:15 [patch 0/6] remove PageReserved Nick Piggin
2005-07-26 8:16 ` [patch 1/6] mm: comment rmap Nick Piggin
2005-07-26 8:17 ` [patch 2/6] mm: micro-optimise rmap Nick Piggin
2005-07-26 8:18 ` [patch 3/6] mm: cleanup rmap Nick Piggin
2005-07-26 8:19 ` [patch 4/6] mm: remove atomic Nick Piggin
2005-07-26 8:20 ` [patch 5/6] mm: remap ZERO_PAGE mappings Nick Piggin
2005-07-26 8:20 ` [patch 6/6] mm: core remove PageReserved Nick Piggin
2005-07-26 8:56 ` [patch 6/6] mm: core remove PageReserved (take 2) Nick Piggin
2005-07-27 11:30 ` [patch 2/6] mm: micro-optimise rmap Alexander Nyberg
2005-07-28 0:53 ` Nick Piggin
2005-07-26 8:21 ` [patch 0/6] remove PageReserved Nick Piggin
2005-07-26 13:09 ` Kumar Gala
2005-07-27 0:22 ` Nick Piggin [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=42E6D3E2.3050601@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=hugh@veritas.com \
--cc=kumar.gala@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox