[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120412123256.GI1787@cmpxchg.org>
Date: Thu, 12 Apr 2012 14:32:56 +0200
From: Johannes Weiner <hannes@...xchg.org>
To: Glauber Costa <glommer@...allels.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
"Daniel P. Berrange" <berrange@...hat.com>,
Li Zefan <lizf@...fujitsu.com>,
LKML <linux-kernel@...r.kernel.org>,
Cgroups <cgroups@...r.kernel.org>,
Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg
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?
> 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.
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists