Messages in this thread | | | Date | Thu, 12 Apr 2012 22:50:23 -0300 | From | Glauber Costa <> | Subject | Re: [RFD] Merge task counter into memcg |
| |
On 04/12/2012 10:42 PM, KAMEZAWA Hiroyuki wrote: > To be honest, I doubt that task counter is unnecessary...memcg can catch > oom situation well. I often test 'make -j' under memcg. > > 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. > Kame,
You're talking about the memcg that is in the kernel today. I think the discussion is orbiting around how it is going to be once we start tracking kernel memory like the slab (for task_struct), or kernel stack pages.
In those scenarios, a fork bomb will be stopped anyway, because it will need kernel memory it can't grab.
| |