aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2007-10-18 06:04:43 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-10-18 17:37:18 -0400
commit2776365370b579afc36cff14dc70a567b66f0378 (patch)
treebc53d79f7c9ef062f2de7e836f44885ac243de35 /Documentation
parentb3dac3b304bdfbb06e92b0d4bba9ecab006795e6 (diff)
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 <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/power/freezing-of-tasks.txt13
1 files changed, 11 insertions, 2 deletions
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
index 04dc1cf9d215..d5c65e8d6a37 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.
81The majority of these are user space processes, but if any of the kernel threads 81The majority of these are user space processes, but if any of the kernel threads
82may cause something like this to happen, they have to be freezable. 82may cause something like this to happen, they have to be freezable.
83 83
842. The second reason is to prevent user space processes and some kernel threads 842. Next, to create the hibernation image we need to free a sufficient amount of
85memory (approximately 50% of available RAM) and we need to do that before
86devices are deactivated, because we generally need them for swapping out. Then,
87after the memory for the image has been freed, we don't want tasks to allocate
88additional memory and we prevent them from doing that by freezing them earlier.
89[Of course, this also means that device drivers should not allocate substantial
90amounts of memory from their .suspend() callbacks before hibernation, but this
91is e separate issue.]
92
933. The third reason is to prevent user space processes and some kernel threads
85from interfering with the suspending and resuming of devices. A user space 94from interfering with the suspending and resuming of devices. A user space
86process running on a second CPU while we are suspending devices may, for 95process running on a second CPU while we are suspending devices may, for
87example, be troublesome and without the freezing of tasks we would need some 96example, 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
111thawed after the driver's .resume() callback has run, so it won't be accessing 120thawed after the driver's .resume() callback has run, so it won't be accessing
112the device while it's suspended. 121the device while it's suspended.
113 122
1143. Another reason for freezing tasks is to prevent user space processes from 1234. Another reason for freezing tasks is to prevent user space processes from
115realizing that hibernation (or suspend) operation takes place. Ideally, user 124realizing that hibernation (or suspend) operation takes place. Ideally, user
116space processes should not notice that such a system-wide operation has occurred 125space processes should not notice that such a system-wide operation has occurred
117and should continue running without any problems after the restore (or resume 126and should continue running without any problems after the restore (or resume