linux-toradex.git/kernel/power/process.c, branch tegra-10.11.7

PM: wakelock: Don't dump unfrozen task list when aborting try_to_freeze_tasks after less than one second

2010-09-30T00:49:07+00:00

Change-Id: Ib2976e5b97a5ee4ec9abd4d4443584d9257d0941
Signed-off-by: Arve Hjønnevåg

PM: wakelock: Abort task freezing if a wake lock is held.

2010-09-30T00:49:07+00:00

Avoids a problem where the device sometimes hangs for 20 seconds
before the screen is turned on.

workqueue: reimplement workqueue freeze using max_active

2010-06-29T08:07:12+00:00

Currently, workqueue freezing is implemented by marking the worker
freezeable and calling try_to_freeze() from dispatch loop.
Reimplement it using cwq->limit so that the workqueue is frozen
instead of the worker.

* workqueue_struct->saved_max_active is added which stores the
  specified max_active on initialization.

* On freeze, all cwq->max_active's are quenched to zero.  Freezing is
  complete when nr_active on all cwqs reach zero.

* On thaw, all cwq->max_active's are restored to wq->saved_max_active
  and the worklist is repopulated.

This new implementation allows having single shared pool of workers
per cpu.

Signed-off-by: Tejun Heo

Freezer: Fix buggy resume test for tasks frozen with cgroup freezer

2010-03-26T22:51:44+00:00

When the cgroup freezer is used to freeze tasks we do not want to thaw
those tasks during resume. Currently we test the cgroup freezer
state of the resuming tasks to see if the cgroup is FROZEN.  If so
then we don't thaw the task. However, the FREEZING state also indicates
that the task should remain frozen.

This also avoids a problem pointed out by Oren Ladaan: the freezer state
transition from FREEZING to FROZEN is updated lazily when userspace reads
or writes the freezer.state file in the cgroup filesystem. This means that
resume will thaw tasks in cgroups which should be in the FROZEN state if
there is no read/write of the freezer.state file to trigger this
transition before suspend.

NOTE: Another "simple" solution would be to always update the cgroup
freezer state during resume. However it's a bad choice for several reasons:
Updating the cgroup freezer state is somewhat expensive because it requires
walking all the tasks in the cgroup and checking if they are each frozen.
Worse, this could easily make resume run in N^2 time where N is the number
of tasks in the cgroup. Finally, updating the freezer state from this code
path requires trickier locking because of the way locks must be ordered.

Instead of updating the freezer state we rely on the fact that lazy
updates only manage the transition from FREEZING to FROZEN. We know that
a cgroup with the FREEZING state may actually be FROZEN so test for that
state too. This makes sense in the resume path even for partially-frozen
cgroups -- those that really are FREEZING but not FROZEN.

Reported-by: Oren Ladaan 
Signed-off-by: Matt Helsley 
Cc: stable@kernel.org
Signed-off-by: Rafael J. Wysocki

Freezer: Only show the state of tasks refusing to freeze

2010-03-26T22:51:13+00:00

show_state will dump all tasks state, so if freezer failed to freeze
any task, kernel will dump all tasks state and flood the dmesg log.
This patch makes freezer only show state of tasks refusing to freeze.

Signed-off-by: Xiaotian Feng 
Acked-by: Pavel Machek 
Acked-by: David Rientjes 
Signed-off-by: Rafael J. Wysocki

PM / freezer: Don't get over-anxious while waiting

2009-10-28T21:53:09+00:00

Freezing isn't exactly the most latency sensitive operation and
there's no reason to burn cpu cycles and power waiting for it to
complete.  msleep(10) instead of yield().  This should improve
reliability of emergency hibernation.

[rjw: Modified the comment next to the msleep(10).]

Signed-off-by: Tejun Heo 
Signed-off-by: Rafael J. Wysocki

oom: move oom_killer_enable()/oom_killer_disable to where they belong

2009-09-22T14:17:38+00:00

Signed-off-by: Alexey Dobriyan 
Acked-by: David Rientjes 
Reviewed-by: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm, PM/Freezer: Disable OOM killer when tasks are frozen

2009-06-17T02:47:40+00:00

Currently, the following scenario appears to be possible in theory:

* Tasks are frozen for hibernation or suspend.
* Free pages are almost exhausted.
* Certain piece of code in the suspend code path attempts to allocate
  some memory using GFP_KERNEL and allocation order less than or
  equal to PAGE_ALLOC_COSTLY_ORDER.
* __alloc_pages_internal() cannot find a free page so it invokes the
  OOM killer.
* The OOM killer attempts to kill a task, but the task is frozen, so
  it doesn't die immediately.
* __alloc_pages_internal() jumps to 'restart', unsuccessfully tries
  to find a free page and invokes the OOM killer.
* No progress can be made.

Although it is now hard to trigger during hibernation due to the memory
shrinking carried out by the hibernation code, it is theoretically
possible to trigger during suspend after the memory shrinking has been
removed from that code path.  Moreover, since memory allocations are
going to be used for the hibernation memory shrinking, it will be even
more likely to happen during hibernation.

To prevent it from happening, introduce the oom_killer_disabled switch
that will cause __alloc_pages_internal() to fail in the situations in
which the OOM killer would have been called and make the freezer set
this switch after tasks have been successfully frozen.

[akpm@linux-foundation.org: be nicer to the namespace]
Signed-off-by: Rafael J. Wysocki 
Cc: Fengguang Wu 
Cc: David Rientjes 
Acked-by: Pavel Machek 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

container freezer: skip frozen cgroups during power management resume

2008-10-20T15:52:34+00:00

When a system is resumed after a suspend, it will also unfreeze frozen
cgroups.

This patchs modifies the resume sequence to skip the tasks which are part
of a frozen control group.

Signed-off-by: Cedric Le Goater 
Signed-off-by: Matt Helsley 
Acked-by: Serge E. Hallyn 
Tested-by: Matt Helsley 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

container freezer: make refrigerator always available

2008-10-20T15:52:33+00:00

Now that the TIF_FREEZE flag is available in all architectures, extract
the refrigerator() and freeze_task() from kernel/power/process.c and make
it available to all.

The refrigerator() can now be used in a control group subsystem
implementing a control group freezer.

Signed-off-by: Cedric Le Goater 
Signed-off-by: Matt Helsley 
Acked-by: Serge E. Hallyn 
Tested-by: Matt Helsley 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds