[lkml]   [2011]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Freezer / Documentation: Update freezer documentation
On Saturday, October 29, 2011, Srivatsa S. Bhat wrote:
> 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 <>

Applied to linux-pm/linux-next.


> ---
> Documentation/power/freezing-of-tasks.txt | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
> diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
> index 38b5724..316c2ba 100644
> --- a/Documentation/power/freezing-of-tasks.txt
> +++ b/Documentation/power/freezing-of-tasks.txt
> @@ -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
> @@ -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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to
> More majordomo info at

 \ /
  Last update: 2011-11-03 01:19    [W:0.044 / U:1.148 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site