Commit:     2776365370b579afc36cff14dc70a567b66f0378
Parent:     b3dac3b304bdfbb06e92b0d4bba9ecab006795e6
Author:     Rafael J. Wysocki <[EMAIL PROTECTED]>
AuthorDate: Thu Oct 18 03:04:43 2007 -0700
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Thu Oct 18 14:37:18 2007 -0700

    freezer: document relationship with memory shrinking
    One important reason to freeze tasks, which is that we don't want them to
    allocate memory after freeing it for the hibernation image, has not been
    documented.  Fix it.
    Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
    Acked-by: Pavel Machek <[EMAIL PROTECTED]>
    Acked-by: Nigel Cunningham <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
 Documentation/power/freezing-of-tasks.txt |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/power/freezing-of-tasks.txt 
index 04dc1cf..d5c65e8 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -81,7 +81,16 @@ hibernation image has been created and before the system is 
finally powered off.
 The majority of these are user space processes, but if any of the kernel 
 may cause something like this to happen, they have to be freezable.
-2. The second reason is to prevent user space processes and some kernel threads
+2. Next, to create the hibernation image we need to free a sufficient amount of
+memory (approximately 50% of available RAM) and we need to do that before
+devices are deactivated, because we generally need them for swapping out.  
+after the memory for the image has been freed, we don't want tasks to allocate
+additional memory and we prevent them from doing that by freezing them earlier.
+[Of course, this also means that device drivers should not allocate substantial
+amounts of memory from their .suspend() callbacks before hibernation, but this
+is e separate issue.]
+3. The third reason is to prevent user space processes and some kernel threads
 from interfering with the suspending and resuming of devices.  A user space
 process running on a second CPU while we are suspending devices may, for
 example, be troublesome and without the freezing of tasks we would need some
@@ -111,7 +120,7 @@ frozen before the driver's .suspend() callback is executed 
and it will be
 thawed after the driver's .resume() callback has run, so it won't be accessing
 the device while it's suspended.
-3. Another reason for freezing tasks is to prevent user space processes from
+4. Another reason for freezing tasks is to prevent user space processes from
 realizing that hibernation (or suspend) operation takes place.  Ideally, user
 space processes should not notice that such a system-wide operation has 
 and should continue running without any problems after the restore (or resume
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to