summaryrefslogtreecommitdiff
path: root/Documentation/power
diff options
context:
space:
mode:
authorLi Fei <fei.li@intel.com>2013-02-01 08:56:03 +0000
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-02-09 22:32:48 +0100
commit957d1282bb8c07e682e142b9237cd9fcb8348a0b (patch)
treea9b5690066c3268e7971c363b34f1a5deb664e2e /Documentation/power
parent89a22dadb8810983868f5bbbc5530b27bf714a60 (diff)
downloadlinux-exynos-957d1282bb8c07e682e142b9237cd9fcb8348a0b.tar.gz
linux-exynos-957d1282bb8c07e682e142b9237cd9fcb8348a0b.tar.bz2
linux-exynos-957d1282bb8c07e682e142b9237cd9fcb8348a0b.zip
suspend: enable freeze timeout configuration through sys
At present, the value of timeout for freezing is 20s, which is meaningless in case that one thread is frozen with mutex locked and another thread is trying to lock the mutex, as this time of freezing will fail unavoidably. And if there is no new wakeup event registered, the system will waste at most 20s for such meaningless trying of freezing. With this patch, the value of timeout can be configured to smaller value, so such meaningless trying of freezing will be aborted in earlier time, and later freezing can be also triggered in earlier time. And more power will be saved. In normal case on mobile phone, it costs real little time to freeze processes. On some platform, it only costs about 20ms to freeze user space processes and 10ms to freeze kernel freezable threads. Signed-off-by: Liu Chuansheng <chuansheng.liu@intel.com> Signed-off-by: Li Fei <fei.li@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'Documentation/power')
-rw-r--r--Documentation/power/freezing-of-tasks.txt5
1 files changed, 5 insertions, 0 deletions
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
index 6ec291ea1c78..85894d83b352 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task, since it is anyway
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
+
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of millisecond.
+The default value is 20000, with range of unsigned integer.