Re: [RFD] Merge task counter into memcg
From: Glauber Costa
Date: Thu Apr 12 2012 - 09:14:11 EST
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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/