All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: ncunningham@cyclades.com
Cc: Linux Memory Management <linux-mm@kvack.org>,
	Pavel Machek <pavel@suse.cz>, Hugh Dickins <hugh@veritas.com>,
	William Lee Irwin III <wli@holomorphy.com>
Subject: Re: PageReserved removal from swsusp
Date: Mon, 25 Jul 2005 14:52:05 +1000	[thread overview]
Message-ID: <42E46FF5.5080805@yahoo.com.au> (raw)
In-Reply-To: <1122265909.6144.106.camel@localhost>

Nigel Cunningham wrote:
> Hi.
> 
>>
>>They're my two ideas. Anyone else?
> 
> 
> I have a few differences in Suspend2 that let me only use one real
> pageflag (Nosave).
> 

Thanks for the reply.

> The changes are:
> 
> 1) Use a set of order zero allocations, tied together via a kmalloc'd
> list of pointers as a means of dynamically creating and destroying
> pseudo page-flags (such as are only needed while suspending). The
> bitmaps don't support sparsemem yet, but this support could be added
> pretty easily.
> 
> 2) This bitmap could be used straight off for swsusp's PageNosave flag
> since it is only used in kernel/power/swsusp.c (2.6.13-rc3 checked).
> 
> 3) Set & Clear PageNosaveFree are also used in mm/page_alloc.c, in
> mark_free_pages, which is only called from swsusp.c, so a dynamically
> allocated bitmap could be used there too.
> 

1,2,3 all sound good. I guess if swsusp becomes any more of a page flag
hog then the page flag bitmap sounds like a good idea. Though at present
it will only allow us to save 1 flag (PageNosaveFree).

I guess I'm mostly interested in how to remove PageReserved usage. That is
one that isn't able to be nicely handled with your pseudo flags bitmap.

> 4) That leaves PageReserved. Pavel and I both rely on a page flag being
> set in the arch specific code (based on e820 tables), so as to know what
> pages are untouchable. As I look more closely though, I wonder if we
> could do without that if we instead directly do the 
> 
> (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))
> 
> and
> 
> (addr < (void *)&__nosave_begin || addr >= (void *)&__nosave_end)
> 
> tests when preparing the image. Assuming, of course, that page_is_ram,
> bad_ppro and page_kills_ppro can be made usable by us.
> 

Well that doesn't sound too unreasonable. Of course you don't want to
use all that directly, but have it put in a nice arch defined wrapper
for you (eg. page_is_usable_ram).

I'm currently playing around with trying to reuse an existing flag
to get this information (instead of PageReserved). But it doesn't seem
like a big problem if we have to fall back to the above.

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 
--
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>

  reply	other threads:[~2005-07-25  4:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-25  1:38 PageReserved removal from swsusp Nick Piggin
2005-07-25  4:31 ` Nigel Cunningham
2005-07-25  4:52   ` Nick Piggin [this message]
2005-07-25  6:22     ` Nick Piggin
2005-07-25  6:59       ` Pavel Machek
2005-07-25 12:39       ` Hugh Dickins
2005-07-25 23:29         ` 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=42E46FF5.5080805@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=hugh@veritas.com \
    --cc=linux-mm@kvack.org \
    --cc=ncunningham@cyclades.com \
    --cc=pavel@suse.cz \
    --cc=wli@holomorphy.com \
    /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.