Re: [RFD] Merge task counter into memcg

[Glauber Costa <glommer@xxxxxxxxxxxxx>]

On 04/12/2012 09:32 AM, Johannes Weiner wrote:
> On Thu, Apr 12, 2012 at 08:43:02AM -0300, Glauber Costa wrote:
> > On 04/12/2012 08:32 AM, Frederic Weisbecker wrote:
> > > > But I think increasing number of subsystem is not very good....
> > > If the result is a better granularity on the overhead, I believe this
> > > can be a good thing.
> >
> > But again, since there is quite number of people trying to merge
> > those stuff together, you are just swimming against the tide.
>
> I don't see where merging unrelated controllers together is being
> discussed, do you have a reference?

https://lkml.org/lkml/2012/2/21/379

But also, I believe this has been widely discussed in person by people, 
in separate groups. Maybe Tejun can do a small writeup of where we stand?

I would also point out that this is exactly what it is (IMHO): an 
ongoing discussion. You are more than welcome to chime in.

> > If this gets really integrated, out of a sudden the overhead will
> > appear. So better care about it now.
>
> Forcing people that want to account/limit one resource to take the hit
> for something else they are not interested in requires justification.

Agree. Even people aiming for unified hierarchies are okay with an 
opt-in/out system, I believe. So the controllers need not to be active 
at all times. One way of doing this is what I suggested to Frederic: If 
you don't limit, don't account.

> You can optimize only so much, in the end, the hierarchical accounting
> is just expensive and unacceptable if you don't care about a certain
> resource.  For that reason, I think controllers should stay opt-in.

see above.

> Btw, can we please have a discussion where raised concerns are
> supported by more than gut feeling?  "I think X is not very good" is
> hardly an argument.  Where is the technical problem in increasing the
> number of available controllers?

Kame said that, not me. But FWIW, I don't disagree. And this is hardly 
gut feeling.

A big number of controllers creates complexity. When coding, we can 
assume a lot less things about their relationships, and more 
importantly: at some point people get confused. Fuck, sometimes *we* get 
confused about which controller do what, where its responsibility end 
and where the other's begin. And we're the ones writing it! Avoiding 
complexity is an engineering principle, not a gut feeling.

Now, of course, we should aim to make things as simple as possible, but 
not simpler: So you can argue that in Frederic's specific case, it is 
justified. And I'd be fine with that 100 %. If I agreed...

There are two natural points for inclusion here:

1) every cgroup has a task counter by itself. If we're putting the tasks 
there anyway, this provides a natural point of accounting.

2) The cpu cgroup, in the end, is the realm of the scheduler. We 
determine which % of the cpu the process will get, bandwidth, time spent 
by tasks, and all that. It is also more natural for that, because it is 
task based.

Don't get me wrong: I actually love the feature Frederic is working on.
I just don't believe a different controller is justified. Nor do I 
believe memcg is the place for that (specially now that I thought it 
overnight)
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers