On Thursday, 26 April 2007 18:10, Pekka Enberg wrote: > > On 4/26/2007, "Rafael J. Wysocki" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 saving). 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. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
