lkml.org 
[lkml]   [2012]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd
On Fri, 6 Apr 2012, Tejun Heo wrote:

> "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.

That doesn't work, the kmem extension to memcg does not allow slab to be
properly accounted to threads in the root memcg. From
Documentation/cgroups/memory.txt section 2.7:

"Kernel memory limits are not imposed for the root cgroup. Usage for the
root cgroup may or may not be accounted."

Kernel memory, I'm sure we'll all agree, is particularly pertinent for
kthreadd and would really be the most interesting reason to ever move it
to a different memcg. This is the use-case that I cited when I said we're
moving in a direction to have nothing in the root memcg, for finer-grained
accounting of kernel memory.

> 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.
>

What about for workqueues?

> 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.

That's a different goal, in my opinion. We already talked about how we
relax the restriction on PF_THREAD_BOUND for both cpusets and cpuacct by
doing -EINVAL for changes to a cgroup that include such threads that are
invalid (for cpusets, changing cpuset.mems to be different than the bound
cpu; for cpu, force rt_runtime for attachment). If we do that then we
don't need any special handling of kthreadd either, which is the direction
in which I thought this discussion was going.

In the interim, however, we need a restriction in place for kthreadd for
both cgroups until such time as that is made a reality. It's not like
we're going to dictate everyone use a signal hierarchy in 3.4.


\
 
 \ /
  Last update: 2012-04-06 22:49    [W:0.102 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site