[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1183696901.3388.119.camel@localhost.localdomain>
Date: Fri, 06 Jul 2007 14:41:40 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Nigel Cunningham <nigel@...el.suspend2.net>
Cc: Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>,
Matthew Garrett <mjg59@...f.ucam.org>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH] Remove process freezer from suspend to RAM pathway
> I/O from swsusp and suspend2 use bios directly, so the page cache isn't an
> issue for them (apart from the fact that Suspend2 saves the page cache
> separately so it can get a full image). Not sure about uswsusp.
>
> Only having half the amount of memory doesn't sound like a big limitation for
> modern desktops & laptops, but don't forget that there are embedded guys
> wanting to hbernate too :)
Wait wait wait ... uses the BIOS ? what do you mean ?
I know that for example, things like MacOS X use a separate polled path to
the storage driver for suspend (works fine for the built-in IDE, but more
complicated in large scale). If you can use BIOS calls to write your
suspend image, that is, if you don't need any of the normal block
infrastructure, then you don't need a freezer ! not at all !
You just do like STR ... and at the end of the day, once you have stopped
all your driver, you shut interrupts off and do the BIOS thing....
I fail to see how processes could dirty pages while/after the BIOS thingy :-)
But then, the problem with that approach is that of course, you need a BIOS
capable of doing that (or a special sideband path to the "blessed" block
driver that will be used for suspend ... not necessarily a hard thing to do,
would be trivial to add support to drivers/ide or libata for that sort of
things I suppose).
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists