> On Fri, Jul 30, 2010 at 07:56:49PM -0400, Ben Blum wrote:
> > This patch series is a revision of
http://lkml.org/lkml/2010/6/25/11 .
> >
> > This patch series implements a write function for the 'cgroup.procs'
> > per-cgroup file, which enables atomic movement of multithreaded
> > applications between cgroups. Writing the thread-ID of any thread in a
> > threadgroup to a cgroup's procs file causes all threads in the group to
> > be moved to that cgroup safely with respect to threads forking/exiting.
> > (Possible usage scenario: If running a multithreaded build system that
> > sucks up system resources, this lets you restrict it all at once into a
> > new cgroup to keep it under control.)
> >
> > Example: Suppose pid 31337 clones new threads 31338 and 31339.
> >
> > # cat /dev/cgroup/tasks
> > ...
> > 31337
> > 31338
> > 31339
> > # mkdir /dev/cgroup/foo
> > # echo 31337 > /dev/cgroup/foo/cgroup.procs
> > # cat /dev/cgroup/foo/tasks
> > 31337
> > 31338
> > 31339
> >
> > A new lock, called threadgroup_fork_lock and living in signal_struct, is
> > introduced to ensure atomicity when moving threads between cgroups. It's
> > taken for writing during the operation, and taking for reading in fork()
> > around the calls to cgroup_fork() and cgroup_post_fork(). I put calls to
> > down_read/up_read directly in copy_process(), since new inline functions
> > seemed like overkill.
> >
> > -- Ben
> >
> > ---
> > Documentation/cgroups/cgroups.txt | 13 -
> > include/linux/init_task.h | 9
> > include/linux/sched.h | 10
> > kernel/cgroup.c | 426 +++++++++++++++++++++++++++++++++-----
> > kernel/cgroup_freezer.c | 4
> > kernel/cpuset.c | 4
> > kernel/fork.c | 16 +
> > kernel/ns_cgroup.c | 4
> > kernel/sched.c | 4
> > 9 files changed, 440 insertions(+), 50 deletions(-)
>
> Here's an updated patchset. I've added an extra patch to implement the
> callback scheme Paul suggested (note how there are twice as many deleted
> lines of code as before :) ), and also moved the up_read/down_read calls
> to static inline functions in sched.h near the other threadgroup-related
> calls.
