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 -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
