On Wed, Apr 11, 2012 at 04:21:42PM -0300, Glauber Costa wrote: > On 04/11/2012 03:57 PM, Frederic Weisbecker wrote: > >So if we choose the second solution, this overhead will be added unconditionally > >to memcg. > >But I don't expect every users of memcg will need the task counter. So perhaps > >the overhead should be kept in its own separate subsystem. > > What we're usually doing with kmem paths, like the upcoming slab > tracking, is do not account if it is not limited. So if you are not > limited in a particular cgroup, you jut don't bother with accounting. So that's a good point. I can start accounting tasks and apply limits once we write to the file only. > > If this suits your need, you can probably do the same, and then > pay the price just for the users that are interested on it. > > Now, whether or not this should be considered memory, is a different > story. You can say it is memory yes, but I bet you can very well > find a bunch of arguments to consider it "cpu" as well. > > Against the memcg, consider this: Your counter would probably be the > first non-page based data in memcg. At least raises a flag. Good points. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
