Messages in this thread | | | Date | Fri, 13 Apr 2012 10:42:24 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFD] Merge task counter into memcg |
| |
(2012/04/13 2:41), Tejun Heo wrote:
> Hello, Johannes.
> I'm still split on the issue. > > * #tasks as unit of accounting / limiting is well understood (or at > least known). I think this holds the same to #open files, to a > lesser extent. It means there are and will continue to be people > wanting them. So, they have some value in familiarity - "but... I > want to limit the resources consumed by tasks cuz that's what I > know!" factor. > > * People could want counting and limiting #tasks or #open files > without the overhead of tracking all memory resources. This stems > from the same reason #tasks was used for this sort of things in the > first place. Counting tasks or open files tends to be easier and > cheaper than tracking all memory allocations. > > 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.
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.
Thanks, -Kame
| |