On Saturday, 28 April 2007 12:49, Rafael J. Wysocki wrote: > On Saturday, 28 April 2007 10:26, Pekka Enberg wrote: > > Nigel Cunningham wrote: > > > I therefore have to ask: Please. Go away. Hand the maintainership of > > > hibernation over to Rafael. Work on things you do care about and where > > > you do want to see a fully functional implementation. But stop being a > > > hindrance to us making Linux hibernation support everything that it > > > ought to be. > > > > [snip] > > > > Please. The load average is a problem and no the fix is not to make > > kernel/timer.c worse for everybody but to snapshot the load averages > > _before_ I/O and restore them after resume. > > I'm having an impression that this problem is suspend2-specific. With swsusp > we can have it only if the writing of snapshot fails. > > Namely, with swsusp we have the pre-snapshot value of the load average in the > image and it should be, so to speak, "normal". Then, once we've restored the > image, this "normal" value gets recovered and everything is fine. If the writing > of image fails, we can have a "wrong" (i.e. too high) value of the load average > afterwards, but then this is an error condition anyway. At least, as a user, I > can expect some glitches to happen after a failing hibernation. > > With suspend2, in turn, the contents of LRU pages are saved before we create > the snapshot. They can be compressed etc. in the process, so the load average > can grow quite substantially and this "unusual" load average is then > snapshotted. Hence, the problem appears after the restore. I think the > solution could be to save the post-tasks-freezing load average and restore it > right before snapshotting, but that's only needed for suspend2. Well, I was wrong. We can have this problem too with swsusp if we need to free much memory before snapshotting the system. Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
