Re: [RFD] Merge task counter into memcg
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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/379But 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.
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
[Cgroups] [Netdev] [Linux Wireless] [Kernel Newbies] [Memory] [Security] [Linux for Hams] [Netfilter] [Bugtraq] [Photo] [Yosemite] [Yosemite Forum] [MIPS Linux] [ARM Linux] [Linux RAID] [Linux Admin] [Find Someone Nice] [Samba] [Video 4 Linux] [Computer Add-ons]