All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Johannes Weiner <jweiner@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <bsingharora@gmail.com>,
	Andrew Brestic <abrestic@google.com>,
	Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] Revert "memcg: add memory.vmscan_stat"
Date: Wed, 31 Aug 2011 08:38:43 +0900	[thread overview]
Message-ID: <20110831083843.25d744bc.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20110830110337.GE13061@redhat.com>

On Tue, 30 Aug 2011 13:03:37 +0200
Johannes Weiner <jweiner@redhat.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@redhat.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





WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Johannes Weiner <jweiner@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <bsingharora@gmail.com>,
	Andrew Brestic <abrestic@google.com>,
	Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] Revert "memcg: add memory.vmscan_stat"
Date: Wed, 31 Aug 2011 08:38:43 +0900	[thread overview]
Message-ID: <20110831083843.25d744bc.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20110830110337.GE13061@redhat.com>

On Tue, 30 Aug 2011 13:03:37 +0200
Johannes Weiner <jweiner@redhat.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@redhat.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-08-30 23:52 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22  8:15 [PATCH v3] memcg: add memory.vmscan_stat KAMEZAWA Hiroyuki
2011-07-22  8:15 ` KAMEZAWA Hiroyuki
2011-08-08 12:43 ` Johannes Weiner
2011-08-08 12:43   ` Johannes Weiner
2011-08-08 23:33   ` KAMEZAWA Hiroyuki
2011-08-08 23:33     ` KAMEZAWA Hiroyuki
2011-08-09  8:01     ` Johannes Weiner
2011-08-09  8:01       ` Johannes Weiner
2011-08-09  8:01       ` KAMEZAWA Hiroyuki
2011-08-09  8:01         ` KAMEZAWA Hiroyuki
2011-08-13  1:04         ` Ying Han
2011-08-13  1:04           ` Ying Han
2011-08-29 15:51     ` [patch] Revert "memcg: add memory.vmscan_stat" Johannes Weiner
2011-08-29 15:51       ` Johannes Weiner
2011-08-30  1:12       ` KAMEZAWA Hiroyuki
2011-08-30  1:12         ` KAMEZAWA Hiroyuki
2011-08-30  7:04         ` Johannes Weiner
2011-08-30  7:04           ` Johannes Weiner
2011-08-30  7:20           ` KAMEZAWA Hiroyuki
2011-08-30  7:20             ` KAMEZAWA Hiroyuki
2011-08-30  7:35             ` KAMEZAWA Hiroyuki
2011-08-30  7:35               ` KAMEZAWA Hiroyuki
2011-08-30  8:42             ` Johannes Weiner
2011-08-30  8:42               ` Johannes Weiner
2011-08-30  8:56               ` KAMEZAWA Hiroyuki
2011-08-30  8:56                 ` KAMEZAWA Hiroyuki
2011-08-30 10:17                 ` Johannes Weiner
2011-08-30 10:17                   ` Johannes Weiner
2011-08-30 10:34                   ` KAMEZAWA Hiroyuki
2011-08-30 10:34                     ` KAMEZAWA Hiroyuki
2011-08-30 11:03                     ` Johannes Weiner
2011-08-30 11:03                       ` Johannes Weiner
2011-08-30 23:38                       ` KAMEZAWA Hiroyuki [this message]
2011-08-30 23:38                         ` KAMEZAWA Hiroyuki
2011-08-30 10:38                   ` KAMEZAWA Hiroyuki
2011-08-30 10:38                     ` KAMEZAWA Hiroyuki
2011-08-30 11:32                     ` Johannes Weiner
2011-08-30 11:32                       ` Johannes Weiner
2011-08-30 23:29                       ` KAMEZAWA Hiroyuki
2011-08-30 23:29                         ` KAMEZAWA Hiroyuki
2011-08-31  6:23                         ` Johannes Weiner
2011-08-31  6:23                           ` Johannes Weiner
2011-08-31  6:30                           ` KAMEZAWA Hiroyuki
2011-08-31  6:30                             ` KAMEZAWA Hiroyuki
2011-08-31  8:33                             ` Johannes Weiner
2011-08-31  8:33                               ` Johannes Weiner
2011-09-01  6:05               ` Ying Han
2011-09-01  6:05                 ` Ying Han
2011-09-01  6:40                 ` Johannes Weiner
2011-09-01  6:40                   ` Johannes Weiner
2011-09-01  7:04                   ` Ying Han
2011-09-01  7:04                     ` Ying Han
2011-09-01  8:27                     ` Johannes Weiner
2011-09-01  8:27                       ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110831083843.25d744bc.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=abrestic@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=yinghan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.