On Sat, 2007-04-28 at 01:45 +0200, Rafael J. Wysocki wrote:On Saturday, 28 April 2007 01:17, Linus Torvalds wrote:
On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
And can you name a _single_ advantage of doing so?
Yes. We have a lot less interdependencies to worry about during the whole
That's not an advantage. That's why it has *sucked*.
Actually, the less things happen while we're creating and saving the image,
the less sources of potential problems there are and by freezing the kernel
threads (not all of them), we cause less things to happen at that time.
To make you happy, we could stop doing that, but what actual _advantage_
that would bring?
A couple of other advantages to freezing other processes:
1) It makes predicting how much memory is available for making and
saving snapshot a tractable problem. It therefore makes hibernation
_much_ more reliable.
2) Racing against other processes would also make hibernation slower,
increasing the chances of your battery running out before the save is
3) It makes finding potential memory leaks in the code possible. It was
ages ago now, but at one stage I could display a table saying exactly
how many pages had been allocated and freed by different sections of the
process and compare the number of free pages at the start and end of the
cycle to ensure there were no memory leaks at all.
NONE of these are valid explanations at all. You're listing totally
theoretical problems, and ignoring all the _real_ problems that trying to
freeze kernel threads has _caused_.
I agree with Rafael. Freezing processes greatly helps in ensuring we
have a consistent image. He's right, too, in asserting that it's even
more important for Suspend2. Freezing processes is essential to being
able to know that those LRU pages won't change and therefore being able
to save them separately and then reuse them for the atomic copy.