Re: Dealing with swsusp vs. pmdisk

[Nigel Cunningham]

Hi.


On Tue, 2004-03-16 at 14:40, Benjamin Herrenschmidt wrote:
> On Tue, 2004-03-16 at 10:31, Nigel Cunningham wrote:
> > On Tue, 2004-03-16 at 13:01, Benjamin Herrenschmidt wrote:
> > > > - 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.
> > > 
> > > It would be nice if you did that as a first step indeed. I'm personally
> > > not convinced of the usefullness of having a freezer at all ;)
> > 
> > Without a freezer, how would you ensure that other processes don't mess
> > up your memory state while you're saving/reloading the image?
> 
> Hrm, you are not protecting about "asynchronous" (interrupt based)
> activity anyway... I'm not sure how the IO sceduler may kill us
> and whatever doing things based on a timer that doesn't have a
> device-driver underneath getting the PM callbacks.

I have other measures to protect the consistency there; forgot about
them until you reminded me. There are simple hooks in the page
allocation and freeing code so that pages allocated and freed during
suspending/resuming come from and go to a fix memory pool. All pages in
this pool are saved with the atomic copy, regardless of whether they're
used or not. This makes the image state consistent even if drivers
allocate or free memory during suspending (including during the
device_suspend/resume calls).

The freezer hooks also catch processes forking or exiting during
suspend, and preserve consistency there too. Right after an init S, the
network code was often seen to be running processes in the middle of a
suspend, after freezing had finished. This works correctly now.

> As far as suspend-to-disk is concerned, I agree we need a state
> snapshot, then we need to be able to play with drivers to save that
> state without having userland get in the way, so yup, we need a
> freezer. I think we don't need it for suspend-to-ram though.

I'll say nothing here; I'm not thinking about suspend-to-ram at all.

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/