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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120405213704.GA29517@google.com>
Date:	Thu, 5 Apr 2012 14:37:04 -0700
From:	Tejun Heo <tj@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mike Galbraith <mgalbraith@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Menage <paul@...lmenage.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/