lkml.org 
[lkml]   [2011]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCHSET] cgroup: introduce cgroup_taskset and consolidate subsys methods
Date
Hello,

cgroup has grown quite some number of subsys methods. Some of them
are overlapping, inconsistent with each other and called under
different conditions depending on whether they're called for a single
task or whole process. Unfortunately, these callbacks are complicated
and incomplete at the same time.

* ->attach_task() is called after migration for task attach but before
for process.

* Ditto for ->pre_attach().

* ->can_attach_task() is called for every task in the thread group but
->attach_task() skips the ones which don't actually change cgroups.

* Task attach becomes noop if the task isn't actually moving. Process
attach is always performed.

* ->attach_task() doesn't (or at least aren't supposed to) have access
to the old cgroup.

* During cancel, there's no way to access the affected tasks.

This patchset introduces cgroup_taskset along with some accessors and
iterator, updates methods to use it, consolidates usages and drops
superflous methods.

It contains the following six patches.

0001-cgroup-subsys-attach_task-should-be-called-after-mig.patch
0002-cgroup-improve-old-cgroup-handling-in-cgroup_attach_.patch
0003-cgroup-introduce-cgroup_taskset-and-use-it-in-subsys.patch
0004-cgroup-don-t-use-subsys-can_attach_task-or-attach_ta.patch
0005-cgroup-cpuset-don-t-use-ss-pre_attach.patch
0006-cgroup-kill-subsys-can_attach_task-pre_attach-and-at.patch

and is based on the current linux-pm/pm-freezer (7b5b95b3f5 "freezer:
remove should_send_signal() and update frozen()"), and available in
the following git tree.

git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git freezer

I based this on top of pm-freezer because cgroup_freezer changes
conflict (easy to resolve but still) and I'm planning on making
further changes to cgroup_freezer which will depend on both freezer
and cgroup changes. How should we route these changes?

1. As this patchset would affect other cgroup changes, it makes sense
to route these through the cgroup branch (BTW, where is it?) and
propagate things there. In that case, I'll re-spin the patches on
top of that tree and send a pull request for the merged branch to
Rafael.

2. Alternatively, if cgroup isn't expected to have too extensive
changes in this cycle, we can just funnel all these through
Rafael's tree.

3. Yet another choice would be applying these on Rafael's tree and
then pull that into cgroup tree as further changes aren't gonna
affect cgroup all that much.

What do you guys think?

Thank you.

Documentation/cgroups/cgroups.txt | 46 +++-----
block/blk-cgroup.c | 45 +++++---
include/linux/cgroup.h | 31 ++++-
kernel/cgroup.c | 200 ++++++++++++++++++++++++--------------
kernel/cgroup_freezer.c | 16 ---
kernel/cpuset.c | 105 +++++++++----------
kernel/events/core.c | 13 +-
kernel/sched.c | 31 +++--
mm/memcontrol.c | 16 +--
security/device_cgroup.c | 7 -
10 files changed, 289 insertions(+), 221 deletions(-)

--
tejun


\
 
 \ /
  Last update: 2011-08-24 00:23    [W:1.247 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site