From: Tejun Heo <tj@kernel.org> To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Glauber Costa <glommer@parallels.com>, Frederic Weisbecker <fweisbec@gmail.com>, Hugh Dickins <hughd@google.com>, Andrew Morton <akpm@linux-foundation.org>, Daniel Walsh <dwalsh@redhat.com>, "Daniel P. Berrange" <berrange@redhat.com>, Li Zefan <lizf@cn.fujitsu.com>, LKML <linux-kernel@vger.kernel.org>, Cgroups <cgroups@vger.kernel.org>, Containers <containers@lists.linux-foundation.org> Subject: Re: [RFD] Merge task counter into memcg Date: Tue, 17 Apr 2012 08:41:17 -0700 [thread overview] Message-ID: <20120417154117.GE32402@google.com> (raw) In-Reply-To: <4F878480.60505@jp.fujitsu.com> Hello, KAMEZAWA. On Fri, Apr 13, 2012 at 10:42:24AM +0900, KAMEZAWA Hiroyuki wrote: > > So, there's spectrum of solutions between merging task counter and > > just directing everyone to kmem without distinguishing task resource > > at all, and at the moment voices in my head are succeeding at making > > cases for both directions. What do you guys think about the above two > > issues? > > > To be honest, I doubt that task counter is unnecessary...memcg can catch > oom situation well. I often test 'make -j' under memcg. Heh, the double negation is confusing me. Were you trying to say that task_counter is necessary or was it the other way around? > To the questions > * It sounds like a 'ulimit' cgroup. How about overwriting > ulimit values via cgroup ? (sounds joke?) Then, overhead will be small but > I'm not sure it can be hierarchical and doesn't break userland. > > If people wants to limit the number of tasks, I think interface should provide it > in the unit of objects. Then, I'm ok to have other subsystem for counting something. > fork-bomb's memory overhead can be prevent by memcg. What memcg cannot handle > is ulimit. If forkbomb exhausts all ulimit/tasks, the user cannot login. > So, having task-limit cgroup subsys for a sandbox will make sense in some situation. > > In short, I don't think it's better to have task-counting and fd-counting in memcg. > It's kmem, but it's more than that, I think. > Please provide subsys like ulimit. So, you think that while kmem would be enough to prevent fork-bombs, it would still make sense to limit in more traditional ways (ie. ulimit style object limits). Hmmm.... Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>, Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Daniel Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> Subject: Re: [RFD] Merge task counter into memcg Date: Tue, 17 Apr 2012 08:41:17 -0700 [thread overview] Message-ID: <20120417154117.GE32402@google.com> (raw) In-Reply-To: <4F878480.60505-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Hello, KAMEZAWA. On Fri, Apr 13, 2012 at 10:42:24AM +0900, KAMEZAWA Hiroyuki wrote: > > So, there's spectrum of solutions between merging task counter and > > just directing everyone to kmem without distinguishing task resource > > at all, and at the moment voices in my head are succeeding at making > > cases for both directions. What do you guys think about the above two > > issues? > > > To be honest, I doubt that task counter is unnecessary...memcg can catch > oom situation well. I often test 'make -j' under memcg. Heh, the double negation is confusing me. Were you trying to say that task_counter is necessary or was it the other way around? > To the questions > * It sounds like a 'ulimit' cgroup. How about overwriting > ulimit values via cgroup ? (sounds joke?) Then, overhead will be small but > I'm not sure it can be hierarchical and doesn't break userland. > > If people wants to limit the number of tasks, I think interface should provide it > in the unit of objects. Then, I'm ok to have other subsystem for counting something. > fork-bomb's memory overhead can be prevent by memcg. What memcg cannot handle > is ulimit. If forkbomb exhausts all ulimit/tasks, the user cannot login. > So, having task-limit cgroup subsys for a sandbox will make sense in some situation. > > In short, I don't think it's better to have task-counting and fd-counting in memcg. > It's kmem, but it's more than that, I think. > Please provide subsys like ulimit. So, you think that while kmem would be enough to prevent fork-bombs, it would still make sense to limit in more traditional ways (ie. ulimit style object limits). Hmmm.... Thanks. -- tejun
next prev parent reply other threads:[~2012-04-17 15:41 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-11 18:57 [RFD] Merge task counter into memcg Frederic Weisbecker 2012-04-11 18:57 ` Frederic Weisbecker [not found] ` <20120411185715.GA4317-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-11 19:21 ` Glauber Costa 2012-04-11 19:21 ` Glauber Costa 2012-04-12 11:19 ` Frederic Weisbecker 2012-04-12 11:19 ` Frederic Weisbecker [not found] ` <4F85D9C6.5000202-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 11:19 ` Frederic Weisbecker 2012-04-12 0:56 ` KAMEZAWA Hiroyuki 2012-04-12 1:07 ` Johannes Weiner 2012-04-12 3:56 ` Alexander Nikiforov [not found] ` <4F86527C.2080507-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-17 15:23 ` Tejun Heo 2012-04-17 15:23 ` Tejun Heo [not found] ` <20120417152350.GC32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-19 3:34 ` Alexander Nikiforov 2012-04-19 3:34 ` Alexander Nikiforov [not found] ` <4F8D1171.1090504-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2012-04-17 15:23 ` Tejun Heo [not found] ` <20120417010902.GA14646-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-12 4:00 ` Alexander Nikiforov 2012-04-12 4:00 ` Alexander Nikiforov 2012-04-12 0:56 ` KAMEZAWA Hiroyuki 2012-04-12 0:56 ` KAMEZAWA Hiroyuki [not found] ` <4F862851.3040208-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-12 11:32 ` Frederic Weisbecker 2012-04-12 11:32 ` Frederic Weisbecker 2012-04-12 11:43 ` Glauber Costa 2012-04-12 11:43 ` Glauber Costa [not found] ` <4F86BFC6.2050400-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 12:32 ` Johannes Weiner 2012-04-12 12:32 ` Johannes Weiner 2012-04-12 12:32 ` Johannes Weiner [not found] ` <20120412123256.GI1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 13:12 ` Glauber Costa 2012-04-12 13:12 ` Glauber Costa 2012-04-12 15:30 ` Johannes Weiner 2012-04-12 15:30 ` Johannes Weiner [not found] ` <20120412153055.GL1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 16:38 ` Tejun Heo 2012-04-12 16:38 ` Tejun Heo [not found] ` <20120412163825.GB13069-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-12 17:04 ` Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter into memcg) Glauber Costa 2012-04-12 17:04 ` Glauber Costa 2012-04-17 15:13 ` Tejun Heo 2012-04-17 15:13 ` Tejun Heo [not found] ` <20120417151352.GA32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-17 15:27 ` Glauber Costa 2012-04-17 15:27 ` Glauber Costa [not found] ` <4F870B18.5060703-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-17 15:13 ` Tejun Heo 2012-04-12 17:13 ` [RFD] Merge task counter into memcg Glauber Costa 2012-04-12 17:13 ` Glauber Costa 2012-04-12 17:23 ` Johannes Weiner 2012-04-12 17:23 ` Johannes Weiner 2012-04-12 17:23 ` Johannes Weiner [not found] ` <20120412172309.GM1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 17:41 ` Tejun Heo 2012-04-12 17:41 ` Tejun Heo 2012-04-12 17:53 ` Glauber Costa 2012-04-12 17:53 ` Glauber Costa 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-17 15:41 ` Tejun Heo [this message] 2012-04-17 15:41 ` Tejun Heo 2012-04-17 16:52 ` Glauber Costa 2012-04-17 16:52 ` Glauber Costa [not found] ` <4F8D9FC4.3080800-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 7:53 ` Frederic Weisbecker 2012-04-18 7:53 ` Frederic Weisbecker 2012-04-18 8:42 ` KAMEZAWA Hiroyuki 2012-04-18 8:42 ` KAMEZAWA Hiroyuki [not found] ` <4F8E7E76.3020202-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 11:00 ` KAMEZAWA Hiroyuki 2012-04-18 11:00 ` KAMEZAWA Hiroyuki [not found] ` <20120418103930.GA1771-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-18 11:00 ` KAMEZAWA Hiroyuki [not found] ` <CAFTL4hw3C4s6VS07pJzdBawv0ugKJJa+Vnb-Q_9FrWEq4=ka9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-18 8:42 ` KAMEZAWA Hiroyuki [not found] ` <4F8E646B.1020807-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-18 7:53 ` Frederic Weisbecker [not found] ` <20120417154117.GE32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-17 16:52 ` Glauber Costa [not found] ` <4F878480.60505-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-13 1:50 ` Glauber Costa 2012-04-13 1:50 ` Glauber Costa 2012-04-13 2:48 ` KAMEZAWA Hiroyuki 2012-04-13 2:48 ` KAMEZAWA Hiroyuki [not found] ` <4F87865F.5060701-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-13 2:48 ` KAMEZAWA Hiroyuki 2012-04-17 15:41 ` Tejun Heo [not found] ` <20120412174155.GC13069-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-12 17:53 ` Glauber Costa 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-12 16:54 ` Glauber Costa 2012-04-12 16:54 ` Glauber Costa 2012-04-12 16:54 ` Glauber Costa [not found] ` <4F86D4BD.1040305-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 15:30 ` Johannes Weiner [not found] ` <20120412113217.GB11455-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-12 11:43 ` Glauber Costa 2012-04-12 1:07 ` Johannes Weiner 2012-04-12 1:07 ` Johannes Weiner [not found] ` <20120412010745.GE1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 2:15 ` Glauber Costa 2012-04-12 2:15 ` Glauber Costa 2012-04-12 3:26 ` Li Zefan 2012-04-12 3:26 ` Li Zefan 2012-04-12 14:55 ` Frederic Weisbecker 2012-04-12 14:55 ` Frederic Weisbecker [not found] ` <20120412145507.GC11455-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-12 16:34 ` Glauber Costa 2012-04-12 16:34 ` Glauber Costa [not found] ` <4F87042A.2000902-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 16:59 ` Frederic Weisbecker 2012-04-12 16:59 ` Frederic Weisbecker 2012-04-17 15:17 ` Tejun Heo 2012-04-17 15:17 ` Tejun Heo 2012-04-18 6:54 ` Frederic Weisbecker 2012-04-18 6:54 ` Frederic Weisbecker 2012-04-18 8:10 ` Frederic Weisbecker 2012-04-18 8:10 ` Frederic Weisbecker [not found] ` <CAFTL4hxXT+hXWEnKop84JQ8ieHX4e=otpHnXYxdxaPgsiZYCiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-18 12:00 ` Glauber Costa 2012-04-18 12:00 ` Glauber Costa 2012-04-18 12:00 ` Glauber Costa 2012-04-18 8:10 ` Frederic Weisbecker [not found] ` <20120417151753.GB32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-18 6:54 ` Frederic Weisbecker [not found] ` <20120412165922.GA12484-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-17 15:17 ` Tejun Heo 2012-04-11 18:57 Frederic Weisbecker
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=20120417154117.GE32402@google.com \ --to=tj@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=berrange@redhat.com \ --cc=cgroups@vger.kernel.org \ --cc=containers@lists.linux-foundation.org \ --cc=dwalsh@redhat.com \ --cc=fweisbec@gmail.com \ --cc=glommer@parallels.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lizf@cn.fujitsu.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.