From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Phillips <phillips@arcor.de>
Cc: linux-kernel@vger.kernel.org,
"Martin J. Bligh" <mbligh@mbligh.org>,
Pavel Machek <pavel@suse.cz>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Memory Management <linux-mm@kvack.org>,
Hugh Dickins <hugh@veritas.com>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Andrea Arcangeli <andrea@suse.de>
Subject: Re: [RFC][patch 0/2] mm: remove PageReserved
Date: Sat, 13 Aug 2005 00:20:10 +0200 [thread overview]
Message-ID: <200508130020.11864.rjw@sisk.pl> (raw)
In-Reply-To: <200508130556.11215.phillips@arcor.de>
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
> > > >> > Swsusp is the main "is valid ram" user I have in mind here. It
> > > >> > wants to know whether or not it should save and restore the
> > > >> > memory of a given `struct page`.
> > > >>
> > > >> Why can't it follow the rmap chain?
> > > >
> > > > It is walking physical memory, not memory managment chains. I need
> > > > something like:
> > >
> > > Can you not use page_is_ram(pfn) ?
> >
> > IMHO it would be inefficient.
> >
> > There obviously are some non-RAM pages that should not be saved and there
> > are some that are not worthy of saving, although they are RAM (eg because
> > they never change), but this is very archtecture-dependent. The arch code
> > should mark them as PageNosave for swsusp, and that's enough.
>
> I still don't see why you can't lift your flags up into the VMA. The rmap
> mechanism is there precisely to let you get from the physical page to the
> users and user data, including VMAs.
I'm not sure if I understand the issue, but swsusp works on a different level.
It only needs to figure out which physical pages, as represented by struct page
objects, should be saved to swap before suspend. We browse all zones (once)
and create a list of page frames that should be saved on the basis of the contents
of the struct page objects alone. IMHO if we needed to use any additional
mechanisms here, it would be less efficient than just checking the page flags.
> I am also not sure why you are talking about efficiency here. Did you measure
> the impact on suspend performance?
I should have said "not enough". The problem is that there may be some page
frames corresponding to RAM (eg such that page_is_ram(pfn) is non-zero) which
for some reason should not be saved on given architecture and we need a
mechanism allowing us to identify them.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-08-12 22:16 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-07 3:28 Nick Piggin
2005-08-07 3:29 ` [patch 1/2] mm: remap ZERO_PAGE mappings Nick Piggin
2005-08-07 3:30 ` [patch 2/2] mm: core remove PageReserved Nick Piggin
2005-08-08 21:09 ` [RFC][patch 0/2] mm: " Daniel Phillips
2005-08-08 21:24 ` Daniel Phillips
2005-08-08 21:54 ` Andrew Morton
2005-08-09 23:23 ` [RFC][PATCH] Rename PageChecked as PageMiscFS Daniel Phillips
2005-08-10 7:48 ` Hugh Dickins
2005-08-10 8:06 ` Daniel Phillips
2005-08-10 22:12 ` Daniel Phillips
2005-08-10 22:23 ` Daniel Phillips
2005-08-10 22:34 ` Trond Myklebust
2005-08-10 22:57 ` Daniel Phillips
2005-08-10 23:23 ` Trond Myklebust
2005-08-11 9:42 ` David Howells
2005-08-10 23:42 ` Adrian Bunk
2005-08-11 9:46 ` David Howells
2005-08-12 2:34 ` Daniel Phillips
2005-08-12 12:32 ` David Howells
2005-08-11 9:31 ` David Howells
2005-08-11 9:26 ` David Howells
2005-08-12 3:29 ` Daniel Phillips
2005-08-12 12:41 ` David Howells
2005-08-12 13:28 ` Hugh Dickins
2005-08-16 13:59 ` Pavel Machek
2005-08-18 14:33 ` David Howells
2005-08-18 22:27 ` Pavel Machek
2005-08-19 10:04 ` David Howells
2005-08-19 16:31 ` Daniel Phillips
2005-08-20 10:45 ` David Howells
2005-08-20 20:21 ` Daniel Phillips
2005-08-10 13:13 ` [RFC][patch 0/2] mm: remove PageReserved David Howells
2005-08-10 13:34 ` Daniel Phillips
2005-08-10 14:27 ` David Howells
2005-08-10 23:19 ` Daniel Phillips
2005-08-11 10:49 ` David Howells
2005-08-12 19:34 ` Daniel Phillips
2005-08-15 13:15 ` David Howells
2005-08-16 1:53 ` Daniel Phillips
2005-08-16 10:28 ` David Howells
2005-08-09 0:15 ` Nick Piggin
2005-08-09 8:51 ` Benjamin Herrenschmidt
2005-08-09 9:49 ` Nick Piggin
2005-08-09 19:19 ` Daniel Phillips
2005-08-09 19:22 ` Daniel Phillips
2005-08-10 21:50 ` Pavel Machek
2005-08-10 21:56 ` Martin J. Bligh
2005-08-11 10:36 ` Rafael J. Wysocki
2005-08-12 19:56 ` Daniel Phillips
2005-08-12 22:20 ` Rafael J. Wysocki [this message]
2005-08-12 23:04 ` Daniel Phillips
2005-08-13 7:06 ` Rafael J. Wysocki
2005-08-11 10:26 ` Rafael J. Wysocki
2005-08-09 11:25 ` Hugh Dickins
2005-08-09 14:31 ` Benjamin Herrenschmidt
2005-08-09 14:50 ` Hugh Dickins
2005-08-09 14:49 ` Benjamin Herrenschmidt
2005-08-09 15:36 ` Hugh Dickins
2005-08-09 21:27 ` Daniel Phillips
2005-08-09 19:14 ` Daniel Phillips
2005-08-09 20:17 ` Hugh Dickins
2005-08-09 20:52 ` Daniel Phillips
2005-08-09 4:39 ` Nigel Cunningham
2005-08-09 4:59 ` Nick Piggin
2005-08-09 5:11 ` Nigel Cunningham
2005-08-09 5:20 ` Nick Piggin
2005-08-09 5:30 ` Nigel Cunningham
2005-08-09 7:08 ` Russell King
2005-08-09 8:38 ` Arjan van de Ven
2005-08-09 9:31 ` Nick Piggin
2005-08-09 9:49 ` Arjan van de Ven
2005-08-09 9:57 ` Nick Piggin
2005-08-09 10:24 ` Rafael J. Wysocki
2005-08-09 8:53 ` Benjamin Herrenschmidt
2005-08-09 9:15 ` Hugh Dickins
2005-08-09 10:27 ` Nick Piggin
2005-08-09 11:15 ` Hugh Dickins
2005-08-09 13:15 ` Nick Piggin
2005-08-09 13:26 ` Arjan van de Ven
2005-08-09 14:28 ` Benjamin Herrenschmidt
2005-08-09 14:47 ` Hugh Dickins
2005-08-09 19:49 ` Roman Zippel
2005-08-09 9:29 ` Nick Piggin
2005-08-09 19:40 ` Russell King
2005-08-09 14:38 ` Martin J. Bligh
2005-08-09 19:41 ` Russell King
2005-08-09 20:51 ` Linus Torvalds
2005-08-09 21:16 ` Martin J. Bligh
2005-08-09 21:51 ` Martin J. Bligh
2005-08-10 9:27 ` Benjamin Herrenschmidt
2005-08-11 9:09 ` Nick Piggin
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=200508130020.11864.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=benh@kernel.crashing.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@mbligh.org \
--cc=nickpiggin@yahoo.com.au \
--cc=pavel@suse.cz \
--cc=phillips@arcor.de \
--cc=torvalds@osdl.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