From: Nigel Cunningham <ncunningham@users.sourceforge.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Dealing with swsusp vs. pmdisk
Date: Tue, 16 Mar 2004 09:05:14 +1300 [thread overview]
Message-ID: <1079381114.5349.62.camel@calvin.wpcb.org.au> (raw)
In-Reply-To: <20040314003717.GI549@elf.ucw.cz>
Hi.
On Sun, 2004-03-14 at 13:37, Pavel Machek wrote:
> On Ne 14-03-04 11:18:02, Benjamin Herrenschmidt wrote:
> > 2.6. I don't see any problem merging it at this point as long as
> > it's not invasive (I haven't looked at the code though). If it's
> > self-contained, it's more/less like adding a driver.
Hi.
The most intrusive parts are:
- Freezer hooks (I can easily get suspend2 working with the old freezer
until people are convinced it's not up to the task). This accounts for
the vast majority of those file changes.
- Changes in vmscan to separate out freeing a single LRU page. When
reading/writing an image, suspend shots down pages added to the LRU list
as a result of it's activities, so as to keep the contents of the LRU
the same as at the start of the cycle. I reckon this might be done by
stopping the pages from being added to the LRU in the first place, but
haven't gotten around to asking whether this can be safely done. (The
current method works, so I haven't made it a priority before now). Short
summary: I freely admit this is ugly and could be done less invasively,
especially with help from some of the MM guys.
- I still have to get the console stuff using file descriptors for I/O
rather than direct calls; I have code there, but it's not being used yet
because it worked and then got broken. (Shouldn't take much to fix).
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
next prev parent reply other threads:[~2004-03-15 22:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 22:46 Pavel Machek
2004-03-13 0:47 ` Theodore Ts'o
2004-03-13 2:51 ` Benjamin Herrenschmidt
2004-03-13 12:36 ` Pavel Machek
2004-03-13 22:19 ` Micha Feigin
2004-03-14 0:18 ` Benjamin Herrenschmidt
2004-03-14 0:37 ` Pavel Machek
2004-03-15 20:05 ` Nigel Cunningham [this message]
2004-03-16 0:01 ` Benjamin Herrenschmidt
2004-03-15 23:31 ` Nigel Cunningham
2004-03-16 1:40 ` Benjamin Herrenschmidt
2004-03-15 23:59 ` Nigel Cunningham
2004-03-16 10:09 ` Pavel Machek
2004-03-13 12:28 ` Pavel Machek
2004-03-15 23:17 ` Jan Rychter
2004-03-16 18:16 ` Kevin Fenzi, Kevin Fenzi
2004-03-18 10:21 ` Jan Rychter
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=1079381114.5349.62.camel@calvin.wpcb.org.au \
--to=ncunningham@users.sourceforge.net \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®