Commit 27763653 authored by Rafael J. Wysocki's avatar Rafael J. Wysocki Committed by Linus Torvalds

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: default avatarRafael J. Wysocki <rjw@sisk.pl>
Acked-by: default avatarPavel Machek <pavel@ucw.cz>
Acked-by: default avatarNigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent b3dac3b3
...@@ -81,7 +81,16 @@ hibernation image has been created and before the system is finally powered off. ...@@ -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 threads The majority of these are user space processes, but if any of the kernel threads
may cause something like this to happen, they have to be freezable. 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. Then,
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 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 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 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 ...@@ -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 thawed after the driver's .resume() callback has run, so it won't be accessing
the device while it's suspended. 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 realizing that hibernation (or suspend) operation takes place. Ideally, user
space processes should not notice that such a system-wide operation has occurred space processes should not notice that such a system-wide operation has occurred
and should continue running without any problems after the restore (or resume and should continue running without any problems after the restore (or resume
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment