[ 08/23] [Suspend2] New freezer explanation for kernel/power/process.c

[Nigel Cunningham]

Modify kernel/power/process.c header to describe how the new freezer
implementation works.

Signed-off-by: Nigel Cunningham <nigel@xxxxxxxxxxxx>

 kernel/power/process.c |   26 +++++++++++++++++++++++---
 1 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index a788186..6da0445 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -1,8 +1,28 @@
 /*
- * drivers/power/process.c - Functions for starting/stopping processes on 
- *                           suspend transitions.
+ * kernel/power/process.c
  *
- * Originally from swsusp.
+ * Copyright (C) 1998-2001 Gabor Kuti <seasons@xxxxxxxxx>
+ * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@xxxxxxx>
+ * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@xxxxxxx>
+ * Copyright (C) 2002-2006 Nigel Cunningham <nigel@xxxxxxxxxxxx>
+ *
+ * This file is released under the GPLv2.
+ *
+ * It contains the routines used to freeze processes during a suspend
+ * cycle (or perhaps in future, a process migration).
+ *
+ * When quiescing the whole system, one process initiates this
+ * functionality by calling freeze_processes(). First, userspace
+ * is frozen. Then bdevs for mounted filesystems are frozen so
+ * as to ensure pending I/O is flushed and stopped. Finally,
+ * kernel threads which are no marked as unfreezeable (perhaps
+ * because they're needed for doing I/O) are frozen. Splitting
+ * kernel threads from userspace also improves reliability,
+ * because it ensures that a userspace thread doesn't deadlock,
+ * waiting for a kernel thread that has already been frozen to
+ * process some request, and because it stops the cause of most
+ * work for kernel threads (ie userspace), allowing those thread
+ * to complete their work more quickly.
  */
 
 

--
Nigel Cunningham		nigel at suspend2 dot net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/