From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>, Linux PM <linux-pm@osdl.org>
Subject: Re: [RFC][PATCH -mm 2/5] swsusp: Use memory bitmaps during resume
Date: Wed, 9 Aug 2006 13:04:35 +0200 [thread overview]
Message-ID: <200608091304.35746.rjw@sisk.pl> (raw)
In-Reply-To: <20060809103442.GJ3308@elf.ucw.cz>
Hi,
On Wednesday 09 August 2006 12:34, Pavel Machek wrote:
> Okay, I'm little out of time now, and I do not understand 2 and 3 in
> the series.
Well ...
> > Make swsusp use memory bitmaps to store its internal information during the
> > resume phase of the suspend-resume cycle.
> >
> > If the pfns of saveable pages are saved during the suspend phase instead of
> > the kernel virtual addresses of these pages, we can use them during the resume
> > phase directly to set the corresponding bits in a memory bitmap. Then, this
> > bitmap is used to mark the page frames corresponding to the pages that were
> > saveable before the suspend (aka "unsafe" page frames).
> >
> > Next, we allocate as many page frames as needed to store the entire suspend
> > image and make sure that there will be some extra free "safe" page frames for
> > the list of PBEs constructed later. Subsequently, the image is loaded and,
> > if possible, the data loaded from it are written into their "original" page frames
> > (ie. the ones they had occupied before the suspend). The image data that
> > cannot be written into their "original" page frames are loaded into "safe" page
> > frames and their "original" kernel virtual addresses, as well as the addresses
> > of the "safe" pages containing their copies, are stored in a list of PBEs.
> > Finally, the list of PBEs is used to copy the remaining image data into their
> > "original" page frames (this is done atomically, by the architecture-dependent
> > parts of swsusp).
>
> So... if page in highmem is allocated during resume, you'll still need
> to copy it during assembly "atomic copy", right?
No. It can be copied before the assembly gets called, because we are in the
kernel at that time which certainly is not in the highmem. :-)
> Unfortunately, our assembler parts can't do it just now...?
No, they can't, but that just isn't necessary. During the resume we create
two lists of PBEs - one for "normal" pages, and one for highmem pages. The
first one is handled by the "atomic copy" code as usual, but the second one
may be handled by some C code a bit earlier.
Rafael
next prev parent reply other threads:[~2006-08-09 11:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 9:52 [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem Rafael J. Wysocki
2006-08-09 9:58 ` [RFC][PATCH -mm 1/5] swsusp: Introduce memory bitmaps Rafael J. Wysocki
2006-08-09 10:31 ` Pavel Machek
2006-08-09 10:57 ` Rafael J. Wysocki
2006-08-09 11:27 ` Pavel Machek
2006-08-09 11:36 ` Rafael J. Wysocki
2006-08-09 11:53 ` Pavel Machek
2006-08-09 12:11 ` Rafael J. Wysocki
2006-08-09 11:46 ` Pavel Machek
2006-08-09 12:02 ` Rafael J. Wysocki
2006-08-09 13:35 ` Pavel Machek
2006-08-09 10:04 ` [RFC][PATCH -mm 2/5] swsusp: Use memory bitmaps during resume Rafael J. Wysocki
2006-08-09 10:34 ` Pavel Machek
2006-08-09 11:04 ` Rafael J. Wysocki [this message]
2006-08-09 11:33 ` Pavel Machek
2006-08-09 11:51 ` Rafael J. Wysocki
2006-08-09 13:33 ` Pavel Machek
2006-08-09 11:49 ` Pavel Machek
2006-08-09 12:04 ` Rafael J. Wysocki
2006-08-09 12:10 ` Pavel Machek
2006-08-09 10:09 ` [RFC][PATCH -mm 3/5] swsusp: Fix handling of highmem Rafael J. Wysocki
2006-08-09 11:51 ` Pavel Machek
2006-08-09 12:07 ` Rafael J. Wysocki
2006-08-09 13:35 ` Pavel Machek
2006-08-09 10:11 ` [RFC][PATCH -mm 4/5] swsusp: Change the name of pagedir_nosave Rafael J. Wysocki
2006-08-09 10:35 ` Pavel Machek
2006-08-09 10:13 ` [RFC][PATCH -mm 5/5] swsusp: Introduce some helpful constants Rafael J. Wysocki
2006-08-09 10:36 ` Pavel Machek
2006-08-09 10:47 ` [RFC][PATCH -mm 0/5] swsusp: Fix handling of highmem Nigel Cunningham
2006-08-09 11:38 ` Pavel Machek
2006-08-09 11:52 ` Nigel Cunningham
2006-08-13 22:34 ` Pavel Machek
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=200608091304.35746.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
--cc=pavel@suse.cz \
/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