public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
	Linux-Kernel <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>,
	linux-pm@lists.linux-foundation.org
Subject: [PATCH 0/6] Container Freezer: Reuse Suspend Freezer
Date: Thu, 31 Jul 2008 22:06:59 -0700	[thread overview]
Message-ID: <20080801050659.924495279@us.ibm.com> (raw)

This patch series introduces a cgroup subsystem that utilizes the swsusp
freezer to freeze a group of tasks. It's immediately useful for batch job
management scripts. It should also be useful in the future for implementing
container checkpoint/restart.

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

* 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

Andrew, since I hear Rafael doesn't have time to review these (again) at this
time, please consider these patches for -mm.

Cheers,
	-Matt Helsley

Changes since v4:
v5:
	Split out write_string as a separate patch for easier merging
		with trees lacking certain cgroup patches at the time.
	Checked use of task alloc lock for races with swsusp freeze/thaw --
		looks safe because there are explicit barriers to handle
		freeze/thaw races for individual tasks, we explicitly
		handle partial group freezing, and partial group thawing
		should be resolved without changing swsusp's loop.
	Updated the patches to Linus' git tree as of approximately
		7/31/2008.
	Added Pavel and Serge's Acked-by lines to Acked patches

v4 (Almost all of these changes are confined to patch 3):
	Reworked the series to use task_lock() instead of RCU.
	Reworked the series to use write_string() and read_seq_string()
		cgroup methods.
	Fixed the race Paul Menage identified.
	Fixed up check_if_frozen() to do more than just test the FROZEN
		flag. In some cases tasks could be stopped (T) and marked
		FREEZING. When that happens we can safely assume that it
		will be frozen immediately upon waking up in the kernel.
		Waiting for it to get marked with PF_FROZEN in order to
		transition to the FROZEN state would block unnecessarily.
	Removed freezer_ prefix from static functions in cgroup_freezer.c.
	Simplified STATE_ switch.
	Updated the locking comments.

v3:
	Ported to 2.6.26-rc5-mm2 with Rafael's freezer patches
	Tested on 24 combinations of 3 architectures (x86, x86_64, ppc64)
		with 8 different kernel configs varying power management
		and cgroup config variables. Each patch builds and boots
		in these 24 combinations.
	Passes functional testing.

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

-- 

             reply	other threads:[~2008-08-01  5:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01  5:06 Matt Helsley [this message]
2008-08-01  5:07 ` [PATCH 1/6] Container Freezer: Add TIF_FREEZE flag to all architectures Matt Helsley
2008-08-01 10:32   ` Nigel Cunningham
2008-08-01 12:32     ` Cedric Le Goater
2008-08-01 22:05       ` Matt Helsley
2008-08-01 22:54         ` Rafael J. Wysocki
2008-08-02  1:13         ` Nigel Cunningham
2008-08-01  5:07 ` [PATCH 2/6] Container Freezer: Make refrigerator always available Matt Helsley
2008-08-01 10:33   ` Nigel Cunningham
2008-08-01 14:27   ` Thomas Petazzoni
2008-08-01 19:08     ` Matt Helsley
2008-08-01 22:53       ` Rafael J. Wysocki
2008-08-01 23:24         ` Matt Helsley
2008-08-02 14:34           ` Rafael J. Wysocki
2008-08-02  2:30         ` Matt Helsley
2008-08-02 10:39       ` Thomas Petazzoni
2008-08-01  5:07 ` [PATCH 3/6] Container Freezer: Implement freezer cgroup subsystem Matt Helsley
2008-08-01 22:58   ` Rafael J. Wysocki
2008-08-02  0:11     ` Matt Helsley
2008-08-02  7:38       ` Cedric Le Goater
2008-08-02 14:37         ` Rafael J. Wysocki
2008-08-01  5:07 ` [PATCH 4/6] Container Freezer: Skip frozen cgroups during power management resume Matt Helsley
2008-08-01 10:24   ` Nigel Cunningham
2008-08-01  5:07 ` [PATCH 5/6] Container Freezer: Prevent frozen tasks or cgroups from changing Matt Helsley
2008-08-01  5:07 ` [PATCH 6/6] Container Freezer: Use cgroup write_string method Matt Helsley
2008-08-01  5:16 ` [PATCH 0/6] Container Freezer: Reuse Suspend Freezer Matt Helsley
2008-08-01 13:04   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080801050659.924495279@us.ibm.com \
    --to=matthltc@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox