|| ||Tejun Heo <firstname.lastname@example.org> |
|| ||email@example.com, firstname.lastname@example.org, email@example.com |
|| ||[PATCHSET] cgroup: introduce cgroup_taskset and consolidate subsys methods |
|| ||Wed, 24 Aug 2011 00:19:54 +0200|
|| ||firstname.lastname@example.org, email@example.com,
|| ||Article, Thread
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
* 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
It contains the following six patches.
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.
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
2. Alternatively, if cgroup isn't expected to have too extensive
changes in this cycle, we can just funnel all these through
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?
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(-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/