Skip to content

RFC Container Freezer: Reuse Suspend Freezer

Matt Helsley containers linux-pm lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest5 patches 49 repliesIn review

v2 (roughly patches 3 and 5) from the cover letter

Moved the "kill" file into a separate cgroup subsystem (signal) and
it's own patch.
Changed the name of the file from freezer.freeze to freezer.state. Switched from taking 1 and 0 as input to the strings "FROZEN" and
"RUNNING", respectively. This helps keep the interface human-usable if/when we need to more states.
Checked that stopped or interrupted is "frozen enough"
Since try_to_freeze() is called upon wakeup of these tasks this should be fine. This idea comes from recent changes to the freezer.
Checked that if (task == current) whilst freezing cgroup we're ok Fixed bug where -EBUSY would always be returned when freezing Added code to handle userspace retries for any remaining -EBUSY

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/5Container Freezer: Add TIF_FREEZE flag to all architecturesinclude/asm-alpha/thread_info.h include/asm-avr32/thread_info.h include/asm-cris/thread_info.h +10 more+25 -00 replies
1/5Container Freezer: Add TIF_FREEZE flag to all architecturesinclude/asm-alpha/thread_info.h include/asm-avr32/thread_info.h include/asm-cris/thread_info.h +10 more+25 -03 replies
2/5Container Freezer: Make refrigerator always availableinclude/linux/freezer.h kernel/Makefile kernel/freezer.c +1 more+133 -1270 replies
2/5Container Freezer: Make refrigerator always availableinclude/linux/freezer.h kernel/Makefile kernel/freezer.c +1 more+133 -12715 replies
3/5Container Freezer: Implement freezer cgroup subsysteminclude/linux/cgroup_freezer.h include/linux/cgroup_subsys.h init/Kconfig +3 more+356 -00 replies
3/5Container Freezer: Implement freezer cgroup subsysteminclude/linux/cgroup_freezer.h include/linux/cgroup_subsys.h init/Kconfig +3 more+356 -015 replies
4/5Container Freezer: Skip frozen cgroups during power management resumekernel/power/process.c+4 -00 replies
4/5Container Freezer: Skip frozen cgroups during power management resumekernel/power/process.c+4 -00 replies
5/5Add a Signal Control Group Subsysteminclude/linux/cgroup_signal.h include/linux/cgroup_subsys.h init/Kconfig +2 more+170 -00 replies
5/5Add a Signal Control Group Subsysteminclude/linux/cgroup_signal.h include/linux/cgroup_subsys.h init/Kconfig +2 more+170 -019 replies

Reviews trailers per patch

None of the 10 patches has a Reviewed-by or Acked-by.

PatchMatt Helsley
SeriesT-b T-b T-b T-b
1/5T-b T-b
1/5T-b T-b
2/5T-b T-b
2/5T-b T-b
3/5T-b T-b
3/5T-b T-b
4/5T-b T-b
4/5T-b T-b
5/5
5/5

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [RFC][PATCH 0/5] Container Freezer: Reuse Suspend Freezer

This patchset reuses the container infrastructure and the swsusp freezer to freeze a group of tasks. I've merely taken Cedric's patches, forward-ported them to 2.6.25-mm1 and tested the expected common cases.

Changes since v1:
v2 (roughly patches 3 and 5):
Moved the "kill" file into a separate cgroup subsystem (signal) and
it's own patch.
Changed the name of the file from freezer.freeze to freezer.state. Switched from taking 1 and 0 as input to the strings "FROZEN" and
"RUNNING", respectively. This helps keep the interface human-usable if/when we need to more states.
Checked that stopped or interrupted is "frozen enough"
Since try_to_freeze() is called upon wakeup of these tasks this should be fine. This idea comes from recent changes to the freezer.
Checked that if (task == current) whilst freezing cgroup we're ok Fixed bug where -EBUSY would always be returned when freezing Added code to handle userspace retries for any remaining -EBUSY

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,signal freezer  /containers/freezer
   # mkdir /containers/freezer/0
   # echo $some_pid > /containers/freezer/0/tasks

to get status of the freezer subsystem :

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

to freeze all tasks in the container :

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

to unfreeze all tasks in the container :

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

to kill all tasks in the container :

   # echo 9 > /containers/freezer/0/signal.kill

* Caveats:

- The cgroup moves into the FROZEN state once all tasks in the cgroup are frozen. This is calculated and changed when the container file "freezer.state" is read or written.
- Frozen containers will be unfrozen when a system is resumed after a suspend. This is addressed by a subsequent patch.

* Series

Applies to 2.6.25-mm1

The first patches make the freezer available to all architectures before implementing the freezer cgroup subsystem.

[RFC PATCH 1/5] Add TIF_FREEZE flag to all architectures [RFC PATCH 2/5] Make refrigerator always available
[RFC PATCH 3/5] Implement freezer cgroup subsystem
[RFC PATCH 4/5] Skip frozen cgroups during power management resume [RFC PATCH 5/5] Implement signal cgroup subsytem

Comments are welcome. I'm planning to finish up testing with ptrace'd and vforking processes and then, if it still seems appropriate, resubmit as a non-RFC series next.

Cheers,
-Matt Helsley