From: David Rientjes <rientjes@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: Mike Galbraith <mgalbraith@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Menage <paul@paulmenage.org>,
LKML <linux-kernel@vger.kernel.org>,
Li Zefan <lizefan@huawei.com>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd
Date: Thu, 5 Apr 2012 14:26:34 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1204051417490.17852@chino.kir.corp.google.com> (raw)
In-Reply-To: <20120405160829.GA12854@google.com>
On Thu, 5 Apr 2012, Tejun Heo wrote:
> > Rebased and separated patches proposed by Mike Galbraith
> > <mgalbraith@suse.de> in https://lkml.org/lkml/2012/1/7/17.
>
> Umm... David, I'm with Peter on this one and don't want kthreadd to go
> anywhere other than the root cgroup. If you know of a valid use case,
> please bring one up; otherwise, I'm applying Mike's patch.
>
Yeah, I know a valid use case, and I'm surprised you don't.
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.
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.
Thanks.
next prev parent reply other threads:[~2012-04-05 21:26 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-03 17:58 [patch] cgroups: disallow attaching kthreadd Mike Galbraith
2012-04-03 18:49 ` Tejun Heo
2012-04-04 2:34 ` Mike Galbraith
2012-04-04 23:06 ` Tejun Heo
2012-04-04 23:10 ` Tejun Heo
2012-04-04 7:15 ` David Rientjes
2012-04-04 10:38 ` Mike Galbraith
2012-04-04 11:29 ` David Rientjes
2012-04-04 12:30 ` Mike Galbraith
2012-04-04 21:17 ` David Rientjes
2012-04-04 23:09 ` Tejun Heo
2012-04-04 23:14 ` David Rientjes
2012-04-05 4:47 ` Mike Galbraith
2012-04-05 4:58 ` David Rientjes
2012-04-05 5:49 ` Mike Galbraith
2012-04-05 6:07 ` David Rientjes
2012-04-05 6:42 ` Mike Galbraith
2012-04-05 6:49 ` David Rientjes
2012-04-05 7:14 ` [patch 0/2] cpusets, cpu_cgroup: " David Rientjes
2012-04-05 7:14 ` [patch 1/2] cpusets: " David Rientjes
2012-04-05 7:14 ` [patch 2/2] cpu_cgroup: " David Rientjes
2012-04-05 16:08 ` [patch 0/2] cpusets, " Tejun Heo
2012-04-05 21:26 ` David Rientjes [this message]
2012-04-05 21:37 ` Tejun Heo
2012-04-05 21:46 ` Tejun Heo
2012-04-06 7:50 ` Li Zefan
2012-04-06 15:54 ` Tejun Heo
2012-04-05 22:03 ` David Rientjes
2012-04-05 22:24 ` Tejun Heo
2012-04-05 22:31 ` Tejun Heo
2012-04-05 22:55 ` David Rientjes
2012-04-05 22:58 ` Tejun Heo
2012-04-05 23:05 ` David Rientjes
2012-04-05 23:13 ` Tejun Heo
2012-04-05 23:40 ` David Rientjes
2012-04-06 15:52 ` Tejun Heo
2012-04-06 18:26 ` Peter Zijlstra
2012-04-06 20:49 ` David Rientjes
2012-04-07 15:02 ` Hiroyuki Kamezawa
2012-04-10 0:52 ` David Rientjes
2012-04-14 11:35 ` Peter Zijlstra
2012-04-20 17:55 ` Tejun Heo
2012-04-06 20:46 ` David Rientjes
2012-04-14 11:28 ` Peter Zijlstra
2012-04-05 7:36 ` [patch] cgroups: " Mike Galbraith
2012-04-05 8:00 ` David Rientjes
2012-04-14 11:17 ` Peter Zijlstra
2012-04-05 16:11 ` Tejun Heo
2012-04-20 17:57 ` Tejun Heo
2012-04-21 5:31 ` Mike Galbraith
2012-04-21 6:54 ` Li Zefan
2012-04-21 7:13 ` Mike Galbraith
2012-04-23 18:05 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1204051417490.17852@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mgalbraith@suse.de \
--cc=mingo@redhat.com \
--cc=paul@paulmenage.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).