From: Andi Kleen <ak@suse.de>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PM <linux-pm@osdl.org>, Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org
Subject: Re: swsusp status report
Date: 26 Jul 2006 17:13:02 +0200 [thread overview]
Message-ID: <p73fygo5ri9.fsf@verdi.suse.de> (raw)
In-Reply-To: <200607251325.14747.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> The code that restores the memory state from the suspend image in step
> (11) also uses the kernel identity mapping to address memory, so it cannot
> access highmem pages on i386, but it practically has no other limitations as
> far as the image size is concerned. In other words, it would be possible to
> restore suspend images as big as 80% or even 90% of RAM, or the normal zone
> on i386, if the 'snapshotting' code were able to create them.
Why can't you just kmap or ioremap them as needed and pass the pfns/struct
page * for IO?
> The code that performs steps (5) and (11) of the suspend-resume cycle is
> quite robust and there is only one known problem with it, which seems to
> be x86_64-specific. Namely, on x86_64 machines with more than 2 GB of RAM
> there are memory gaps and/or reserved memory areas between the 2nd and 3rd
> Gbyte of physical memory and swsusp tries to save these areas as though
> they were RAM which leads to oopses. This issue is now being worked on.
I guess we could just borrow a new struct page flags bit again and set it
during memory setup. That would fix your problem I guess. Should be fairly
easy to do. Let me know if you need it.
-Andi
next prev parent reply other threads:[~2006-07-26 15:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 11:25 swsusp status report Rafael J. Wysocki
2006-07-25 15:11 ` Dave Jones
2006-07-25 19:39 ` Rafael J. Wysocki
2006-07-25 19:39 ` Rafael J. Wysocki
2006-07-26 10:08 ` Pavel Machek
2006-07-26 15:13 ` Andi Kleen [this message]
2006-07-26 17:38 ` Rafael J. Wysocki
2006-07-26 17:38 ` Rafael J. Wysocki
2006-07-26 15:40 ` Alan Stern
2006-07-26 17:37 ` Rafael J. Wysocki
2006-07-27 20:40 ` Pavel Machek
2006-07-27 23:13 ` David Brownell
2006-07-28 23:46 ` 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=p73fygo5ri9.fsf@verdi.suse.de \
--to=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/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.