Messages in this thread | | | Subject | Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd | From | Peter Zijlstra <> | Date | Fri, 06 Apr 2012 20:26:10 +0200 |
| |
On Fri, 2012-04-06 at 08:52 -0700, Tejun Heo wrote: > Hello, David. > > On Thu, Apr 05, 2012 at 04:40:06PM -0700, David Rientjes wrote: > > Well, I'm fussing over it because the patch being considered unnecessary > > requires that kthreadd can't be moved anywhere and I know one company is > > trying to move in a direction where nothing is in the root memcg. > > "Nothing in the root memcg" can't be a goal in and of itself. You > want that to achieve some functional goal and I'm trying to say this > specific kthreadd change doesn't necessarily affect the goal - better > accounting - all that much. If root group is gonna be completely > empty otherwise, just combine information from it. Even if that > doesn't work, assigning specific kthreads to appropriate cgroups after > the creation wouldn't be too far off. I just don't see how relevant > it actually would be. > > If we want all controlles to play by the same rules, which is > necessary for having a unified hierarchy, I wanna keep those rules > simple. If bound kthreads in !root cgroups cause issues for some and > there aren't quite strong reasons to do otherwise, I would just > restrict them in the root. It's not like those kthreads are > cgroup-aware in any form anyway. > > I don't know. Just proceed without kthreadd in the root. If the > fallouts are big enough and can't be easily worked around, let's talk > then.
Furthermore, the whole point of kthreadd's existence is so that we could create kthreads without context. Placing it in a cgroup will ensure all subsequently created kthreads do have context (including possible idle threads). This seems like a particularly bad idea.
| |