linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Hiroyuki Kamezawa <kamezawa.hiroyuki@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Mike Galbraith <mgalbraith@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>, Paul Menage <paul@paulmenage.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Li Zefan <lizefan@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd
Date: Fri, 20 Apr 2012 10:55:14 -0700	[thread overview]
Message-ID: <20120420175514.GE32324@google.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1204091747470.4449@chino.kir.corp.google.com>

Hello,

On Mon, Apr 09, 2012 at 05:52:50PM -0700, David Rientjes wrote:
> On Sun, 8 Apr 2012, Hiroyuki Kamezawa wrote:
> 
> > I'm sorry if I didn't read e-mails while a trip....let me understand...
> > 
> >  - Tejun at el, tries to disallow to move kthreadd into cgroups other than root.
> >  - You wants to account kthreadd's activity under memg at el.
> > 
> 
> memcg isn't the only use case, you can also use it for cpuacct and any 
> other future cgroup that wants to do so.
> 
> > Then, 2 question from me is....
> > 1. If this patch only affects kthreadd, you can move other
> >     kthread. Is this correct ?
> > 
> 
> Yes, but not those that are forked by kthreadd at runtime without some 
> delay between the fork and attaching it to a different cgroup.  With memcg 
> slab accounting, for example, allocating the task_struct for the kthread 
> should appropriately be accounted for in a non-root memcg.
> 
> Keep in mind that this isn't only limited to memcg, I've just used it to 
> illustrate how account for slab is useful.  I don't know everybody's use 
> cases where they may want to do the same thing so I've been arguing 
> against unnecessarily restricting it from all cgroups other than those 
> that require it (cpuset and cpu).
> 
> Using cpusets as an example, we can even completely remove the restriction 
> on attaching all PF_THREAD_BOUND threads by not allowing them only if the 
> destination cpuset has mems that are disjoint from the bound cpu and 
> disallow changing the mems to be disjoint from a member's bound cpu.

So, the scheduler / arch people don't seem too happy with the prospect
of basic system kthreads living in !root cgroups and memcg people seem
willing to fix up whatever accounting deficiency in root memcg and I'm
not convinced the left use cases are all that useful / important.
There inherently are system-wide things (things happen w/o task
context and thus w/o any cgroup associated).  Just leave them in the
rootcg.  If you have to move kthreads to !root cgroups for accounting,
then do so on your own.  The only downsides are small delays and kmem
accounting inaccuracy from kthread allocation.

Thanks.

-- 
tejun

  parent reply	other threads:[~2012-04-20 17:55 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
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 [this message]
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=20120420175514.GE32324@google.com \
    --to=tj@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyuki@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mgalbraith@suse.de \
    --cc=mingo@redhat.com \
    --cc=paul@paulmenage.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    /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).