Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

[Tejun Heo <tj@kernel.org>]

Hello, David.

On Thu, Apr 05, 2012 at 02:26:34PM -0700, David Rientjes wrote:
> Yeah, I know a valid use case, and I'm surprised you don't.

Yeah, I'm pretty good at surprising people that way.

> Google is moving in a direction where nothing will be assigned to the root 
> memcg.  We already have a seperate memcg for accounting of memory 
> allocated by the kernel, i.e. memory not accounted toward any user job.  
> We will be doing this more aggressively in the future once we have setup 
> memcg hierarchies to differentiate the memory usage of the kernel 
> including workqueues created by kthreadd and have complete coverage of 
> memory accounting such as slab and memory allocated directly from 
> __get_free_pages().  We don't want anything in the root memcg itself.

Ambitious and I'm not even sure that's even possible without fallback
default group.  There just are things which are system-wide.  What's
wrong with using root cgroup for that?

> It's also possible to attach kthreadd to the cpuacct cgroup for similar 
> accounting.  The idea is that not all cgroups impose limits, either for 
> memcg (where memory.limit_in_bytes == ULONG_MAX) or cpuacct, but rather 
> purely for accounting.
> 
> For cpusets and the cpu cgroup, I completely agree with disallowing 
> kthreadd and that's why I've passed along these patches.  However, it's 
> not necessary (or even preferred for our usecase) to restrict kthreadd 
> from being attached to all cgroups.  Yes, it's a global resource.  We want 
> to account for the memory of that global resource.

Unfortunately, mainline cgroup is moving towards single hierarchy -
well, that's the plan anyway - and in that light ->can_attach() is
essentially broken and will thus be grdually phased out.  From the
look of the current users, I don't think it's gonna be hard.  cpu
cgroup would have to learn to ignore tasks with special scheduling
class and the blkcg silliness needs to go away but that seems to be
it.

So, hmmm, how about just using root cgroup for the fallback?

Thanks.

-- 
tejun