(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
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
