cgroup: status-quo and userland efforts
tj at kernel.org
Sat Apr 6 01:21:59 UTC 2013
It's been about a year since I wrote up a summary on cgroup status quo
and future plans. We're not there yet but much closer than we were
before. At least the locking and object life-time management aren't
crazy anymore and most controllers now support proper hierarchy
although not all of them agree on how to treat inheritance.
IIRC, the yet-to-be-converted ones are blk-throttle and perf. cpu
needs to be updated so that it at least supports a similar mechanism
as cfq-iosched for configuring ratio between tasks on an internal
cgroup and its children. Also, we really should update how cpuset
handles a cgroup becoming empty (no cpus or memory node left due to
hot-unplug). It currently transfers all its tasks to the nearest
ancestor with executing resources, which is an irreversible process
which would affect all other co-mounted controllers. We probably want
it to just take on the masks of the ancestor until its own executing
resources become online again, and the new behavior should be gated
behind a switch (Li, can you please look into this?).
While we have still ways to go, I feel relatively confident saying
that we aren't too far out now, well, except for the writeback mess
that still needs to be tackled. Anyways, once the remaining bits are
settled, we can proceed to implement the unified hierarchy mode I've
been talking about forever. I can't think of any fundamental
roadblocks at the moment but who knows? The devil usually is in the
details. Let's hope it goes okay.
So, while we aren't moving as fast as we wish we were, the kernel side
of things are falling into places. At least, that's how I see it.
More information about the Containers