Skip to content

Commit

Permalink
PM / Sleep: Update freezer documentation
Browse files Browse the repository at this point in the history
This patch:
 * Substitutes some obsolete references to kernel/power/process.c by
   kernel/freezer.c.
 * Mentions kernel/freezer.c as being part of the "freezer" code along
   with the rest of the files.
 * Fixes a trivial typo.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
  • Loading branch information
Srivatsa S. Bhat authored and Rafael J. Wysocki committed Nov 4, 2011
1 parent 4e71c95 commit e9db50b
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions Documentation/power/freezing-of-tasks.txt
Original file line number Diff line number Diff line change
Expand Up @@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
either wakes them up, if they are kernel threads, or sends fake signals to them,
if they are user space processes. A task that has TIF_FREEZE set, should react
to it by calling the function called refrigerator() (defined in
kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state
kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
Then, we say that the task is 'frozen' and therefore the set of functions
handling this mechanism is referred to as 'the freezer' (these functions are
defined in kernel/power/process.c and include/linux/freezer.h). User space
processes are generally frozen before kernel threads.
defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
User space processes are generally frozen before kernel threads.

It is not recommended to call refrigerator() directly. Instead, it is
recommended to use the try_to_freeze() function (defined in
Expand Down Expand Up @@ -95,7 +95,7 @@ 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.]
is a 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
Expand Down

0 comments on commit e9db50b

Please sign in to comment.