Eric Lee / smarc-fsl-linux-kernel

18 May, 2011

1 commit

  • ee940d8dc   Freezer: Use SMP barriers ... Browse Code »

    The freezer processes are dealing with multiple threads running
    simultaneously, and on a UP system, the memory reads/writes do
    not need barriers to keep things in sync. These are only needed
    on SMP systems, so use SMP barriers instead.

    Signed-off-by: Mike Frysinger
    Acked-by: Pavel Machek
    Signed-off-by: Rafael J. Wysocki

    Mike Frysinger
     

24 Dec, 2010

1 commit

  • 8cfe400ca   Freezer: Fix a race during freezing of TASK_STOPPED tasks ... Browse Code »

    After calling freeze_task(), try_to_freeze_tasks() see whether the
    task is stopped or traced and if so, considers it to be frozen;
    however, nothing guarantees that either the task being frozen sees
    TIF_FREEZE or the freezer sees TASK_STOPPED -> TASK_RUNNING
    transition. The task being frozen may wake up and not see TIF_FREEZE
    while the freezer fails to notice the transition and believes the task
    is still stopped.

    This patch fixes the race by making freeze_task() always go through
    fake_signal_wake_up() for applicable tasks. The function goes through
    the target task's scheduler lock and thus guarantees that either the
    target sees TIF_FREEZE or try_to_freeze_task() sees TASK_RUNNING.

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

    Tejun Heo
     

18 Jul, 2009

1 commit

  • 6301cb95c   sched: fix nr_uninterruptible accounting of frozen tasks really ... Browse Code »

    commit e3c8ca8336 (sched: do not count frozen tasks toward load) broke
    the nr_uninterruptible accounting on freeze/thaw. On freeze the task
    is excluded from accounting with a check for (task->flags &
    PF_FROZEN), but that flag is cleared before the task is thawed. So
    while we prevent that the task with state TASK_UNINTERRUPTIBLE
    is accounted to nr_uninterruptible on freeze we decrement
    nr_uninterruptible on thaw.

    Use a separate flag which is handled by the freezing task itself. Set
    it before calling the scheduler with TASK_UNINTERRUPTIBLE state and
    clear it after we return from frozen state.

    Cc:
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

31 Oct, 2008

1 commit

20 Oct, 2008

2 commits

  • dc52ddc0e   container freezer: implement freezer cgroup subsystem ... Browse Code »

    This patch implements a new freezer subsystem in the control groups
    framework. It provides a way to stop and resume execution of all tasks in
    a cgroup by writing in the cgroup filesystem.

    The freezer subsystem in the container filesystem defines a file named
    freezer.state. Writing "FROZEN" to the state file will freeze all tasks
    in the cgroup. Subsequently writing "RUNNING" will unfreeze the tasks in
    the cgroup. Reading will return the current state.

    * Examples of usage :

    # mkdir /containers/freezer
    # mount -t cgroup -ofreezer freezer /containers
    # mkdir /containers/0
    # echo $some_pid > /containers/0/tasks

    to get status of the freezer subsystem :

    # cat /containers/0/freezer.state
    RUNNING

    to freeze all tasks in the container :

    # echo FROZEN > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    FREEZING
    # cat /containers/0/freezer.state
    FROZEN

    to unfreeze all tasks in the container :

    # echo RUNNING > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    RUNNING

    This is the basic mechanism which should do the right thing for user space
    task in a simple scenario.

    It's important to note that freezing can be incomplete. In that case we
    return EBUSY. This means that some tasks in the cgroup are busy doing
    something that prevents us from completely freezing the cgroup at this
    time. After EBUSY, the cgroup will remain partially frozen -- reflected
    by freezer.state reporting "FREEZING" when read. The state will remain
    "FREEZING" until one of these things happens:

    1) Userspace cancels the freezing operation by writing "RUNNING" to
    the freezer.state file
    2) Userspace retries the freezing operation by writing "FROZEN" to
    the freezer.state file (writing "FREEZING" is not legal
    and returns EIO)
    3) The tasks that blocked the cgroup from entering the "FROZEN"
    state disappear from the cgroup's set of tasks.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: export thaw_process]
    Signed-off-by: Cedric Le Goater
    Signed-off-by: Matt Helsley
    Acked-by: Serge E. Hallyn
    Tested-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     
  • 8174f1503   container freezer: make refrigerator always available ... Browse Code »

    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

    Matt Helsley