Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

From: Rafael J. Wysocki
Date: Thu Apr 26 2007 - 15:24:56 EST

On Thursday, 26 April 2007 18:10, Pekka Enberg wrote:
> On 4/26/2007, "Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
> > In principle, we could add suspend2 as an alternative (in analogy with the I/O
> > schedulers, for example), but I think for this purpose it should be reviewed
> > properly.
> Yeah, this makes sense.
> On 4/26/2007, "Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
> > There also is a real problem with how it uses the LRU pages. It _seems_ to
> > work, but at least to me it seems to be potentially dangerous.
> I am new to suspend2 so can you please explain what exactly is dangerous
> about it?

After freezing tasks, it first saves the contents of the LRU pages, freezes
devices and then uses the LRU pages for storing the suspend image (if more
memory is needed, it's allocated, but that's irrelevant here). Now, we have no
warranty that the LRU pages are not updated after we've saved their contents
(first potential problem here).

After the image has been created, we have to unfreeze devices and save the
image. Now, we have no warranty that no one will be writing to the LRU pages
that we have used to store the image, for whatever reasons known to him, so the
image can potentially get corrupted while it's being saved.

In principle, device drivers can do this and there are some kernel threads that
also can do this (we don't freeze them, because they're needed for the image

The design is conceptually really really complicated and it makes strong
assumptions about the behavior of different subsystems. While these
assumptions _may_ be satisfied right now, we'd have to ensure the satisfaction
of them in the future if suspend2 were merged.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at