On Saturday, 28 April 2007 23:25, Linus Torvalds wrote: > > On Sat, 28 Apr 2007, Rafael J. Wysocki wrote: > > > > > > The freezer has *caused* those deadlocks (eg by stopping threads that > > > were > > > needed for the suspend writeouts to succeed!), not solved them. > > > > I can't remember anything like this, but I believe you have a specific test > > case in mind. > > Ehh.. Why do you thik we _have_ that PF_NOFREEZE thing in the first place?
Well, I don't know why exactly it had been originally introduced. Currently, it is used by the threads that should be running after the snapshot is done (they are not only I/O threads). > Rafael, you really don't know what you're talking about, do you? I think I know. > Just _look_ at them. It's the IO threads etc that shouldn't be frozen, > exactly *because* they do IO. You claim that kernel threads shouldn't do > IO, but that's the point: if you cannot do IO when snapshotting to disk, > here's a damn big clue for you: how do you think that snapshot is going to > get written? OK, more precisely: fs-related threads should not try to process their queues, etc., after the snapshot is done, because that may cause some fs data to be written at that time and then the fs in question may be corrupted after the restore. Not all of the I/O in general, fs data. Still, that alone probably is not a good enough reason for freezing all kernel threads. > I *guarantee* you that we've had a lot more problems with threads that > should *not* have been frozen than with those hypothetical threads that > you think should have been frozen. Well, I'm not sure whether or not that still would have been the case if we had stopped to freeze kernel threads for the hibernation/suspend. I just see potential problems that I've mentioned in the previous message and I don't see any evidence that they cannot occur. 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/
