lkml.org 
[lkml]   [2012]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-04-13 03:55    [W:0.087 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site