[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110831083843.25d744bc.kamezawa.hiroyu@jp.fujitsu.com>
Date: Wed, 31 Aug 2011 08:38:43 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Johannes Weiner <jweiner@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Daisuke Nishimura <nishimura@....nes.nec.co.jp>,
Balbir Singh <bsingharora@...il.com>,
Andrew Brestic <abrestic@...gle.com>,
Ying Han <yinghan@...gle.com>, Michal Hocko <mhocko@...e.cz>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] Revert "memcg: add memory.vmscan_stat"
On Tue, 30 Aug 2011 13:03:37 +0200
Johannes Weiner <jweiner@...hat.com> wrote:
> On Tue, Aug 30, 2011 at 07:34:06PM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 30 Aug 2011 12:17:26 +0200
> > Johannes Weiner <jweiner@...hat.com> wrote:
> > How about fixing interface first ? 1st version of this patch was
> > in April and no big change since then.
> > I don't want to be starved more.
>
> Back then I mentioned all my concerns and alternate suggestions.
> Different from you, I explained and provided a reason for every single
> counter I wanted to add, suggested a basic pattern for how to
> interpret them to gain insight into memcg configurations and their
> behaviour. No reaction. If you want to make progress, than don't
> ignore concerns and arguments. If my arguments are crap, then tell me
> why and we can move on.
>
I think having percpu couneter has no performance benefit, just lose
extra memory by percpu allocation.
Anyway, you can change internal implemenatation when it's necessary.
But Ok, I agree using the same style as zone counters is better.
> What we have now is not ready. It wasn't discussed properly, which
> certainly wasn't for the lack of interest in this change. I just got
> tired of raising the same points over and over again without answer.
>
> The amount of time a change has been around is not an argument for it
> to get merged. On the other hand, the fact that it hasn't changed
> since April *even though* the implementation was opposed back then
> doesn't really speak for your way of getting this upstream, does it?
The fact is that you should revert the patch when it's merged to mmotm.
Please revert patch. And merge your own.
Anyway I don't have much interests in hierarchy.
Bye,
-Kame
--
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