On 04/12/2012 02:41 PM, Tejun Heo wrote:
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?
About each of your points:
1) Quite honestly, if we were implementing what people say they want...
We'd have a lisp interpreter in the kernel by now.
At the very best, it is an issue of getting the communication right.
I really don't think this is of any concern.
2) It is dependent on the previous question/answer. Do people really
want to account and limit that? Or do they just think they want?
Also note that we need to make memcg cheaper anyway... And right not it
is not *that* expensive if you are not doing deep hierarchy.
user pages get cached through the stock mechanism, slab pages are not
very frequently allocated (because first you need to exhaust the objects
on the slab, etc)
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
