OpenVZ Forum - RDF feed
type: channel
items: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
items: [RFC PATCH 1/4] Container Freezer: Add TIF_FREEZE flag to all architectures
items: [RFC PATCH 2/4] Container Freezer: Make refrigerator always available
items: [RFC PATCH 3/4] Container Freezer: Implement freezer cgroup subsystem
items: Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
items: Re: [RFC PATCH 1/4] Container Freezer: Add TIF_FREEZE flag to all architectures
items: Re: [RFC PATCH 3/4] Container Freezer: Implement freezer cgroup subsystem

[RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: NOTE: Due to problems with my MTA configuration two earlier attempts reached linux-pm but not linux-kernel. Please cc linux-pm@lists.linux-foundation.org on replies. This patchset is a prototype using 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-rc8-mm1 and done a small amount of testing. 2 files are defined by the freezer subsystem in the container filesystem : * "freezer.freeze" writing 1 will freeze all tasks and 0 unfreeze reading will return the status of the freezer * "freezer.kill" writing <n> will send signal number <n> to all tasks * Usage : # mkdir /containers/freezer # mount -t container -ofreezer 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.freeze RUNNING to freeze all tasks in the container : # echo 1 > /containers/freezer/0/freezer.freeze # cat /containers/freezer/0/freezer.freeze FREEZING # cat /containers/freezer/0/freezer.freeze FROZEN to unfreeze all tasks in the container : # echo 1 > /containers/freezer/0/freezer.freeze # cat /containers/freezer/0/freezer.freeze RUNNING to kill all tasks in the container : # echo 9 > /containers/freezer/0/freezer.kill * Caveats: - the FROZEN status is calculated and changed when the container file "freezer.freeze" is read. - frozen containers will be unfrozen when a system is resumed after a suspend. This is addressed by the last patch. * Series Applies to 2.6.25-rc8-mm1 The first patches make the freezer available to all architectures before implementing the freezer subsystem. [RFC PATCH 1/4] Add TIF_FREEZE flag to all architectures [RFC PATCH 2/4] Make refrigerator always available [RFC PATCH 3/4] Implement freezer cgroup subsystem [RFC PATCH 4/4] Skip frozen cgroups during power management resume Each patch compiles, boots, and survives basic LTP containers and controllers tes…
creator: Matt Helsley
date: 2008-04-03T21:03:16-00:00

[RFC PATCH 1/4] Container Freezer: Add TIF_FREEZE flag to all architectures
type: item
description: This patch is the first step in making the refrigerator() available to all architectures, even for those without power management. The purpose of such a change is to be able to use the refrigerator() in a new control group subsystem which will implement a control group freezer. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> Tested-by: Matt Helsley <matthltc@us.ibm.com> Cc: linux-pm@lists.linux-foundation.org --- include/asm-alpha/thread_info.h | 2 ++ include/asm-avr32/thread_info.h | 2 ++ include/asm-cris/thread_info.h | 2 ++ include/asm-h8300/thread_info.h | 2 ++ include/asm-m68k/thread_info.h | 1 + include/asm-m68knommu/thread_info.h | 2 ++ include/asm-parisc/thread_info.h | 2 ++ include/asm-s390/thread_info.h | 2 ++ include/asm-sparc/thread_info.h | 2 ++ include/asm-sparc64/thread_info.h | 2 ++ include/asm-um/thread_info.h | 2 ++ include/asm-v850/thread_info.h | 2 ++ include/asm-xtensa/thread_info.h | 2 ++ 13 files changed, 25 insertions(+) Index: 2.6.25-rc3-mm1/include/asm-alpha/thread_info.h =================================================================== --- 2.6.25-rc3-mm1.orig/include/asm-alpha/thread_info.h +++ 2.6.25-rc3-mm1/include/asm-alpha/thread_info.h @@ -76,12 +76,14 @@ register struct thread_info *__current_t #define TIF_UAC_SIGBUS 7 #define TIF_MEMDIE 8 #define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal */ +#define TIF_FREEZE 19 /* is freezing for suspend */ #define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE) #define _TIF_SIGPENDING (1<<TIF_SIGPENDING) #define _TIF_NEED_RESCHED (1<<TIF_NEED_RESCHED) #define _TIF_POLLING_NRFLAG (1<<TIF_POLLING_NRFLAG) #define _TIF_RESTORE_SIGMASK (1<<TIF_RESTORE_SIGMASK) +#define _TIF_FREEZE (1<<TIF_FREEZE) /* Work to do on interrupt/exception return. */ #define _TIF_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED) Index: 2.6.25-rc3-mm1/include/asm-avr32/thread_info.h =================================================================== --- 2.6.25-rc3-m…
creator: Matt Helsley
date: 2008-04-03T21:03:17-00:00

[RFC PATCH 2/4] Container Freezer: Make refrigerator always available
type: item
description: 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 <clg@fr.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> Tested-by: Matt Helsley <matthltc@us.ibm.com> Cc: linux-pm@lists.linux-foundation.org --- Changelog: Merged Roland's "STOPPED is frozen enough" changes. For details see: http://lkml.org/lkml/2008/3/3/676 include/linux/freezer.h | 19 ++----- kernel/Makefile | 2 kernel/freezer.c | 124 ++++++++++++++++++++++++++++++++++++++++++++++++ kernel/power/process.c | 113 ------------------------------------------- 4 files changed, 132 insertions(+), 126 deletions(-) Index: linux-2.6.25-rc8-mm1/include/linux/freezer.h =================================================================== --- linux-2.6.25-rc8-mm1.orig/include/linux/freezer.h +++ linux-2.6.25-rc8-mm1/include/linux/freezer.h @@ -4,11 +4,10 @@ #define FREEZER_H_INCLUDED #include <linux/sched.h> #include <linux/wait.h> -#ifdef CONFIG_PM_SLEEP /* * Check if a process has been frozen */ static inline int frozen(struct task_struct *p) { @@ -61,22 +60,27 @@ static inline int thaw_process(struct ta task_unlock(p); return 0; } extern void refrigerator(void); -extern int freeze_processes(void); -extern void thaw_processes(void); static inline int try_to_freeze(void) { if (freezing(current)) { refrigerator(); return 1; } else return 0; } +extern int freeze_task(struct task_struct *p, int with_mm_only); + +#ifdef CONFIG_PM_SLEEP + +extern int freeze_processes(void); +extern void thaw_processes(void); + /* * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it * calls wait_for_completion(&vfork) and reset right after it returns from this * function. Next, the parent should call try_to_freeze() to freeze itself * appropriately in case the child has e…
creator: Matt Helsley
date: 2008-04-03T21:03:18-00:00

[RFC PATCH 3/4] Container Freezer: Implement freezer cgroup subsystem
type: item
description: This patch implements a new freezer subsystem for Paul Menage's control groups framework. It provides a way to stop and resume execution of all tasks in a cgroup by writing in the cgroup filesystem. This is the basic mechanism which should do the right thing for user space tasks in a simple scenario. This will require more work to get the freezing right (cf. try_to_freeze_tasks()) for ptraced tasks. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> Tested-by: Matt Helsley <matthltc@us.ibm.com> Cc: linux-pm@lists.linux-foundation.org --- include/linux/cgroup_freezer.h | 57 ++++++++ include/linux/cgroup_subsys.h | 6 init/Kconfig | 7 + kernel/Makefile | 1 kernel/cgroup_freezer.c | 280 +++++++++++++++++++++++++++++++++++++++++ kernel/freezer.c | 1 6 files changed, 352 insertions(+) Index: linux-2.6.25-rc8-mm1/include/linux/cgroup_freezer.h =================================================================== --- /dev/null +++ linux-2.6.25-rc8-mm1/include/linux/cgroup_freezer.h @@ -0,0 +1,57 @@ +#ifndef _LINUX_CGROUP_FREEZER_H +#define _LINUX_CGROUP_FREEZER_H +/* + * cgroup_freezer.h - control group freezer subsystem interface + * + * Copyright IBM Corp. 2007 + * + * Author : Cedric Le Goater <clg@fr.ibm.com> + */ + +#include <linux/cgroup.h> + +#ifdef CONFIG_CGROUP_FREEZER + +enum freezer_state { + STATE_RUNNING = 0, + STATE_FREEZING, + STATE_FROZEN, +}; + +struct freezer { + struct cgroup_subsys_state css; + enum freezer_state state; + spinlock_t lock; +}; + +static inline struct freezer *cgroup_freezer( + struct cgroup *cgroup) +{ + return container_of( + cgroup_subsys_state(cgroup, freezer_subsys_id), + struct freezer, css); +} + +static inline int cgroup_frozen(struct task_struct *task) +{ + struct cgroup *cgroup = task_cgroup(task, freezer_subsys_id); + struct freezer *freezer = cgroup_freezer(cgroup); + enum freezer_state state; + + spin_lock(&freezer->lock); + state = freezer->state; + spin_unlock(&freezer->lock); + …
creator: Matt Helsley
date: 2008-04-03T21:03:19-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: > > * "freezer.kill" > > writing <n> will send signal number <n> to all tasks > My first thought (not having looked at the code yet) is that sending a signal doesn't really have anything to do with freezing, so it shouldn't be in the same subsystem. Maybe a separate subsystem called "signal"? And more than that, it's not something that requires any particular per-process state, so there's no reason that the subsystem that provides the "kill" functionality shouldn't be able to be mounted in multiple hierarchies. How about if I added support for stateless subsystems, that could potentially be mounted in multiple hierarchies at once? They wouldn't need an entry in the css set, since they have no state. > * Usage : > > # mkdir /containers/freezer > # mount -t container -ofreezer 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.freeze > RUNNING > > to freeze all tasks in the container : > > # echo 1 > /containers/freezer/0/freezer.freeze > # cat /containers/freezer/0/freezer.freeze > FREEZING > # cat /containers/freezer/0/freezer.freeze > FROZEN Could we separate this out into two files? One called "freeze" that's a 0/1 for whether we're intending to freeze the subsystem, and one called "frozen" that indicates whether it is frozen? And maybe a "state" file to report the RUNNING/FREEZING/FROZEN distinction in a human-readable way? Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2008-04-03T23:49:24-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: > On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: > > > > * "freezer.kill" > > > > writing <n> will send signal number <n> to all tasks > > > > My first thought (not having looked at the code yet) is that sending a > signal doesn't really have anything to do with freezing, so it > shouldn't be in the same subsystem. Maybe a separate subsystem called > "signal"? > > And more than that, it's not something that requires any particular > per-process state, so there's no reason that the subsystem that > provides the "kill" functionality shouldn't be able to be mounted in > multiple hierarchies. > > How about if I added support for stateless subsystems, that could > potentially be mounted in multiple hierarchies at once? They wouldn't > need an entry in the css set, since they have no state. This seems reasonable to me. A quick look at Cedric's patches suggests there's no need for such cgroup subsystems to be tied together -- the signalling is all done internally to the freeze_task(), refrigerator(), and thaw_process() functions from what I recall. > > * Usage : > > > > # mkdir /containers/freezer > > # mount -t container -ofreezer 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.freeze > > RUNNING > > > > to freeze all tasks in the container : > > > > # echo 1 > /containers/freezer/0/freezer.freeze > > # cat /containers/freezer/0/freezer.freeze > > FREEZING > > # cat /containers/freezer/0/freezer.freeze > > FROZEN > > Could we separate this out into two files? One called "freeze" that's > a 0/1 for whether we're intending to freeze the subsystem, and one > called "frozen" that indicates whether it is frozen? And maybe a > "state" file to report the RUNNING/FREEZING/FROZEN distinction in a > human-readable way? 3 files seems like overkill. I think maki…
creator: Matt Helsley
date: 2008-04-04T03:03:00-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: Quoting Paul Menage (menage@google.com): > On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: > > > > * "freezer.kill" > > > > writing <n> will send signal number <n> to all tasks > > > > My first thought (not having looked at the code yet) is that sending a > signal doesn't really have anything to do with freezing, so it > shouldn't be in the same subsystem. Maybe a separate subsystem called > "signal"? > > And more than that, it's not something that requires any particular > per-process state, so there's no reason that the subsystem that > provides the "kill" functionality shouldn't be able to be mounted in > multiple hierarchies. > > How about if I added support for stateless subsystems, that could > potentially be mounted in multiple hierarchies at once? They wouldn't > need an entry in the css set, since they have no state. > > > * Usage : > > > > # mkdir /containers/freezer > > # mount -t container -ofreezer 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.freeze > > RUNNING > > > > to freeze all tasks in the container : > > > > # echo 1 > /containers/freezer/0/freezer.freeze > > # cat /containers/freezer/0/freezer.freeze > > FREEZING > > # cat /containers/freezer/0/freezer.freeze > > FROZEN > > Could we separate this out into two files? One called "freeze" that's > a 0/1 for whether we're intending to freeze the subsystem, and one > called "frozen" that indicates whether it is frozen? And maybe a > "state" file to report the RUNNING/FREEZING/FROZEN distinction in a > human-readable way? One thing Oren had mentioned for checkpoint/restart was having more states - i.e. restoring, checkpointing... So then (assuming we used this subsys for that) we'd have more than the two files. Which is probably fine, just wanted to point that out. -serge _______________________________________________ Containers …
creator: serue
date: 2008-04-04T14:11:06-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: Matt Helsley wrote: > On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: >> On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: >>> * "freezer.kill" >>> >>> writing <n> will send signal number <n> to all tasks >>> >> My first thought (not having looked at the code yet) is that sending a >> signal doesn't really have anything to do with freezing, so it >> shouldn't be in the same subsystem. Maybe a separate subsystem called >> "signal"? >> >> And more than that, it's not something that requires any particular >> per-process state, so there's no reason that the subsystem that >> provides the "kill" functionality shouldn't be able to be mounted in >> multiple hierarchies. >> >> How about if I added support for stateless subsystems, that could >> potentially be mounted in multiple hierarchies at once? They wouldn't >> need an entry in the css set, since they have no state. > > This seems reasonable to me. A quick look at Cedric's patches suggests > there's no need for such cgroup subsystems to be tied together -- the > signalling is all done internally to the freeze_task(), refrigerator(), > and thaw_process() functions from what I recall. > >>> * Usage : >>> >>> # mkdir /containers/freezer >>> # mount -t container -ofreezer 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.freeze >>> RUNNING >>> >>> to freeze all tasks in the container : >>> >>> # echo 1 > /containers/freezer/0/freezer.freeze >>> # cat /containers/freezer/0/freezer.freeze >>> FREEZING >>> # cat /containers/freezer/0/freezer.freeze >>> FROZEN >> Could we separate this out into two files? One called "freeze" that's >> a 0/1 for whether we're intending to freeze the subsystem, and one >> called "frozen" that indicates whether it is frozen? And maybe a >> "state" file to report the RUNNING/FREEZING/FROZEN distinction in a >> human-readable w…
creator: Oren Laadan
date: 2008-04-04T15:56:43-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: On Fri, 2008-04-04 at 11:56 -0400, Oren Laadan wrote: > > Matt Helsley wrote: > > On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: > >> On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: > >>> * "freezer.kill" > >>> > >>> writing <n> will send signal number <n> to all tasks > >>> > >> My first thought (not having looked at the code yet) is that sending a > >> signal doesn't really have anything to do with freezing, so it > >> shouldn't be in the same subsystem. Maybe a separate subsystem called > >> "signal"? > >> > >> And more than that, it's not something that requires any particular > >> per-process state, so there's no reason that the subsystem that > >> provides the "kill" functionality shouldn't be able to be mounted in > >> multiple hierarchies. > >> > >> How about if I added support for stateless subsystems, that could > >> potentially be mounted in multiple hierarchies at once? They wouldn't > >> need an entry in the css set, since they have no state. > > > > This seems reasonable to me. A quick look at Cedric's patches suggests > > there's no need for such cgroup subsystems to be tied together -- the > > signalling is all done internally to the freeze_task(), refrigerator(), > > and thaw_process() functions from what I recall. > > > >>> * Usage : > >>> > >>> # mkdir /containers/freezer > >>> # mount -t container -ofreezer 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.freeze > >>> RUNNING > >>> > >>> to freeze all tasks in the container : > >>> > >>> # echo 1 > /containers/freezer/0/freezer.freeze > >>> # cat /containers/freezer/0/freezer.freeze > >>> FREEZING > >>> # cat /containers/freezer/0/freezer.freeze > >>> FROZEN > >> Could we separate this out into two files? One called "freeze" that's > >> a 0/1 for whether we're intending to freeze the subsystem, and one > >> cal…
creator: Matt Helsley
date: 2008-04-04T22:27:40-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: Matt Helsley wrote: > On Fri, 2008-04-04 at 11:56 -0400, Oren Laadan wrote: >> Matt Helsley wrote: >>> On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: >>>> On Thu, Apr 3, 2008 at 2:03 PM, <matthltc@us.ibm.com> wrote: >>>>> * "freezer.kill" >>>>> >>>>> writing <n> will send signal number <n> to all tasks >>>>> >>>> My first thought (not having looked at the code yet) is that sending a >>>> signal doesn't really have anything to do with freezing, so it >>>> shouldn't be in the same subsystem. Maybe a separate subsystem called >>>> "signal"? >>>> >>>> And more than that, it's not something that requires any particular >>>> per-process state, so there's no reason that the subsystem that >>>> provides the "kill" functionality shouldn't be able to be mounted in >>>> multiple hierarchies. >>>> >>>> How about if I added support for stateless subsystems, that could >>>> potentially be mounted in multiple hierarchies at once? They wouldn't >>>> need an entry in the css set, since they have no state. >>> This seems reasonable to me. A quick look at Cedric's patches suggests >>> there's no need for such cgroup subsystems to be tied together -- the >>> signalling is all done internally to the freeze_task(), refrigerator(), >>> and thaw_process() functions from what I recall. >>> >>>>> * Usage : >>>>> >>>>> # mkdir /containers/freezer >>>>> # mount -t container -ofreezer 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.freeze >>>>> RUNNING >>>>> >>>>> to freeze all tasks in the container : >>>>> >>>>> # echo 1 > /containers/freezer/0/freezer.freeze >>>>> # cat /containers/freezer/0/freezer.freeze >>>>> FREEZING >>>>> # cat /containers/freezer/0/freezer.freeze >>>>> FROZEN >>>> Could we separate this out into two files? One called "freeze" that's >>>> a 0/1 for whether we're intending to freeze the subsystem,…
creator: Oren Laadan
date: 2008-04-05T00:30:33-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: On Fri, 2008-04-04 at 20:30 -0400, Oren Laadan wrote: > > Matt Helsley wrote: <snip> > > I don't have an upper limit on how many more states we will need and I > > think that number impacts the interface significantly. Can you give us > > an estimate? > > In Zap there are (using the current terminology): > RUNNING - running > FREEZING - transition to FROZEN > FROZEN - frozen > THAWING - transition to RUNNING > CKPTING - being checkpointed (needs special semantics* for some ops) > RSTRTING - being restarted (may need special semantics* for some ops) > ABORTING - transition to DEAD (mainly when aborting a failed restart) > DEAD - dead (but not fully cleaned up yet) > > There is also "SPECIAL" in which some operations are not allowed; > this simplifies dealing with a bunch of races related to checkpoint/ > restart, but I'm not sure it's a must. If anything, it only stays > for very short times (like an uninterruptible sleep) saying "don't > mess with this container now, it's busy". > > I have very good justifications for almost all the states, a good > reasoning for DEAD, and a case for SPECIAL (although there may be > a way to do without it). > > Despite the "many" states, there are very few transitions: CKPTING > can only be reached from- and changed to- FROZEN. A similar rule holds > for RSTRTING. ABORTING is reached from RSTRTING, and leads to DEAD. > The only one I don't cover is reaching DEAD from any other state > (except SPECIAL) but I never saw a reason to explicitly encode that. > Something like this (without SPECIAL): > > -> FREEZING -> <-> CKPTING > RUNNING FROZEN > <- THAWING <- <-> RSTRTING -> ABORTING -> DEAD > > Out of curiosity - why does the number of states impact the interface > so much ? Only that, if you're trying to keep the interface human readable, then having too many names for things (states and transitions) can make the interface less than intuitive. Doesn't look like that's an issue for the above state machine though so I think you're right…
creator: Matt Helsley
date: 2008-04-05T00:54:03-00:00

Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
type: item
description: Hi! > NOTE: Due to problems with my MTA configuration two earlier attempts reached linux-pm > but not linux-kernel. Please cc linux-pm@lists.linux-foundation.org on replies. > > This patchset is a prototype using 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-rc8-mm1 and done a small amount of > testing. Okay, freezer probably does what you want, but be warned that Linus is not exactly in love with freezer. You probably can get away with using it for user processes, but maybe you should drop him the line saying you want to expand freezer usage and see what happens. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Machek
date: 2008-04-11T11:49:22-00:00

Re: [RFC PATCH 1/4] Container Freezer: Add TIF_FREEZE flag to all architectures
type: item
description: On Thu 2008-04-03 14:03:17, matthltc@us.ibm.com wrote: > This patch is the first step in making the refrigerator() available > to all architectures, even for those without power management. > > The purpose of such a change is to be able to use the refrigerator() > in a new control group subsystem which will implement a control group > freezer. > > Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> > Signed-off-by: Matt Helsley <matthltc@us.ibm.com> > Tested-by: Matt Helsley <matthltc@us.ibm.com> > Cc: linux-pm@lists.linux-foundation.org ACK. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Machek
date: 2008-04-11T11:49:30-00:00

Re: [RFC PATCH 3/4] Container Freezer: Implement freezer cgroup subsystem
type: item
description: Hi! > This patch implements a new freezer subsystem for Paul Menage's > control groups framework. It provides a way to stop and resume > execution of all tasks in a cgroup by writing in the cgroup > filesystem. > > This is the basic mechanism which should do the right thing for > user space tasks in a simple scenario. This will require more work > to get the freezing right (cf. try_to_freeze_tasks()) for ptraced > tasks. > --- /dev/null > +++ linux-2.6.25-rc8-mm1/include/linux/cgroup_freezer.h > @@ -0,0 +1,57 @@ > +#ifndef _LINUX_CGROUP_FREEZER_H > +#define _LINUX_CGROUP_FREEZER_H > +/* > + * cgroup_freezer.h - control group freezer subsystem interface > + * > + * Copyright IBM Corp. 2007 > + * > + * Author : Cedric Le Goater <clg@fr.ibm.com> > + */ If you have copyright, add GPL. > --- /dev/null > +++ linux-2.6.25-rc8-mm1/kernel/cgroup_freezer.c > @@ -0,0 +1,280 @@ > +/* > + * cgroup_freezer.c - control group freezer subsystem > + * > + * Copyright IBM Corp. 2007 > + * > + * Author : Cedric Le Goater <clg@fr.ibm.com> > + */ Same here. >+static struct cgroup_subsys_state *freezer_create( >+ struct cgroup_subsys *ss, struct cgroup *cgroup) >+{ Function headers are somehow non-traditional. + struct freezer *freezer; + + if (!capable(CAP_SYS_ADMIN)) + return ERR_PTR(-EPERM); + + freezer = kzalloc(sizeof(struct freezer), GFP_KERNEL); + if (!freezer) + return ERR_PTR(-ENOMEM); + + spin_lock_init(&freezer->lock); + freezer->state = STATE_RUNNING; + return &freezer->css; +} One space too many after "return" :-). Hmm, returning pointer inside struct freezer is rather ugly, right? Could you just pass struct freezer around? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Machek
date: 2008-04-11T11:49:47-00:00