All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Rik van Riel <riel@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc patch 2/6] vmscan: make distinction between memcg reclaim and LRU list selection
Date: Thu, 12 May 2011 18:03:49 +0200	[thread overview]
Message-ID: <20110512160349.GJ16531@cmpxchg.org> (raw)
In-Reply-To: <4DCBFDB9.10209@redhat.com>

On Thu, May 12, 2011 at 11:33:13AM -0400, Rik van Riel wrote:
> On 05/12/2011 10:53 AM, Johannes Weiner wrote:
> >The reclaim code has a single predicate for whether it currently
> >reclaims on behalf of a memory cgroup, as well as whether it is
> >reclaiming from the global LRU list or a memory cgroup LRU list.
> >
> >Up to now, both cases always coincide, but subsequent patches will
> >change things such that global reclaim will scan memory cgroup lists.
> >
> >This patch adds a new predicate that tells global reclaim from memory
> >cgroup reclaim, and then changes all callsites that are actually about
> >global reclaim heuristics rather than strict LRU list selection.
> >
> >Signed-off-by: Johannes Weiner<hannes@cmpxchg.org>
> >---
> >  mm/vmscan.c |   96 ++++++++++++++++++++++++++++++++++------------------------
> >  1 files changed, 56 insertions(+), 40 deletions(-)
> >
> >diff --git a/mm/vmscan.c b/mm/vmscan.c
> >index f6b435c..ceeb2a5 100644
> >--- a/mm/vmscan.c
> >+++ b/mm/vmscan.c
> >@@ -104,8 +104,12 @@ struct scan_control {
> >  	 */
> >  	reclaim_mode_t reclaim_mode;
> >
> >-	/* Which cgroup do we reclaim from */
> >-	struct mem_cgroup *mem_cgroup;
> >+	/*
> >+	 * The memory cgroup we reclaim on behalf of, and the one we
> >+	 * are currently reclaiming from.
> >+	 */
> >+	struct mem_cgroup *memcg;
> >+	struct mem_cgroup *current_memcg;
> 
> I can't say I'm fond of these names.  I had to read the
> rest of the patch to figure out that the old mem_cgroup
> got renamed to current_memcg.

To clarify: sc->memcg will be the memcg that hit the hard limit and is
the main target of this reclaim invocation.  current_memcg is the
iterator over the hierarchy below the target.

I realize this change in particular was placed a bit unfortunate in
terms of understanding in the series, I just wanted to keep out the
mem_cgroup to current_memcg renaming out of the next patch.  There is
probably a better way, I'll fix it up and improve the comment.

> Would it be better to call them my_memcg and reclaim_memcg?
> 
> Maybe somebody else has better suggestions...

Yes, suggestions welcome.  I'm not too fond of the naming, either.

> Other than the naming, no objection.

Thanks, Rik.

	Hannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Rik van Riel <riel@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc patch 2/6] vmscan: make distinction between memcg reclaim and LRU list selection
Date: Thu, 12 May 2011 18:03:49 +0200	[thread overview]
Message-ID: <20110512160349.GJ16531@cmpxchg.org> (raw)
In-Reply-To: <4DCBFDB9.10209@redhat.com>

On Thu, May 12, 2011 at 11:33:13AM -0400, Rik van Riel wrote:
> On 05/12/2011 10:53 AM, Johannes Weiner wrote:
> >The reclaim code has a single predicate for whether it currently
> >reclaims on behalf of a memory cgroup, as well as whether it is
> >reclaiming from the global LRU list or a memory cgroup LRU list.
> >
> >Up to now, both cases always coincide, but subsequent patches will
> >change things such that global reclaim will scan memory cgroup lists.
> >
> >This patch adds a new predicate that tells global reclaim from memory
> >cgroup reclaim, and then changes all callsites that are actually about
> >global reclaim heuristics rather than strict LRU list selection.
> >
> >Signed-off-by: Johannes Weiner<hannes@cmpxchg.org>
> >---
> >  mm/vmscan.c |   96 ++++++++++++++++++++++++++++++++++------------------------
> >  1 files changed, 56 insertions(+), 40 deletions(-)
> >
> >diff --git a/mm/vmscan.c b/mm/vmscan.c
> >index f6b435c..ceeb2a5 100644
> >--- a/mm/vmscan.c
> >+++ b/mm/vmscan.c
> >@@ -104,8 +104,12 @@ struct scan_control {
> >  	 */
> >  	reclaim_mode_t reclaim_mode;
> >
> >-	/* Which cgroup do we reclaim from */
> >-	struct mem_cgroup *mem_cgroup;
> >+	/*
> >+	 * The memory cgroup we reclaim on behalf of, and the one we
> >+	 * are currently reclaiming from.
> >+	 */
> >+	struct mem_cgroup *memcg;
> >+	struct mem_cgroup *current_memcg;
> 
> I can't say I'm fond of these names.  I had to read the
> rest of the patch to figure out that the old mem_cgroup
> got renamed to current_memcg.

To clarify: sc->memcg will be the memcg that hit the hard limit and is
the main target of this reclaim invocation.  current_memcg is the
iterator over the hierarchy below the target.

I realize this change in particular was placed a bit unfortunate in
terms of understanding in the series, I just wanted to keep out the
mem_cgroup to current_memcg renaming out of the next patch.  There is
probably a better way, I'll fix it up and improve the comment.

> Would it be better to call them my_memcg and reclaim_memcg?
> 
> Maybe somebody else has better suggestions...

Yes, suggestions welcome.  I'm not too fond of the naming, either.

> Other than the naming, no objection.

Thanks, Rik.

	Hannes

--
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-05-12 16:04 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12 14:53 [rfc patch 0/6] mm: memcg naturalization Johannes Weiner
2011-05-12 14:53 ` Johannes Weiner
2011-05-12 14:53 ` [rfc patch 1/6] memcg: remove unused retry signal from reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 15:02   ` Rik van Riel
2011-05-12 15:02     ` Rik van Riel
2011-05-12 17:22     ` Ying Han
2011-05-12 23:44   ` KAMEZAWA Hiroyuki
2011-05-12 23:44     ` KAMEZAWA Hiroyuki
2011-05-13  9:23   ` Michal Hocko
2011-05-13  9:23     ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 2/6] vmscan: make distinction between memcg reclaim and LRU list selection Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 15:33   ` Rik van Riel
2011-05-12 15:33     ` Rik van Riel
2011-05-12 16:03     ` Johannes Weiner [this message]
2011-05-12 16:03       ` Johannes Weiner
2011-05-17  6:38       ` Ying Han
2011-05-17  6:38         ` Ying Han
2011-05-17  8:25         ` Johannes Weiner
2011-05-17  8:25           ` Johannes Weiner
2011-05-12 23:50   ` KAMEZAWA Hiroyuki
2011-05-12 23:50     ` KAMEZAWA Hiroyuki
2011-05-13  6:58     ` Johannes Weiner
2011-05-13  6:58       ` Johannes Weiner
2011-05-16 22:36       ` Andrew Morton
2011-05-16 22:36         ` Andrew Morton
2011-05-12 14:53 ` [rfc patch 3/6] mm: memcg-aware global reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 16:04   ` Rik van Riel
2011-05-12 16:04     ` Rik van Riel
2011-05-12 19:19   ` Ying Han
2011-05-13  7:08     ` Johannes Weiner
2011-05-13  7:08       ` Johannes Weiner
2011-05-13  0:04   ` KAMEZAWA Hiroyuki
2011-05-13  0:04     ` KAMEZAWA Hiroyuki
2011-05-13  7:18     ` Johannes Weiner
2011-05-13  7:18       ` Johannes Weiner
2011-05-13  0:40   ` KAMEZAWA Hiroyuki
2011-05-13  0:40     ` KAMEZAWA Hiroyuki
2011-05-13  6:54     ` Johannes Weiner
2011-05-13  6:54       ` Johannes Weiner
2011-05-13  9:53   ` Michal Hocko
2011-05-13  9:53     ` Michal Hocko
2011-05-13 10:28     ` Johannes Weiner
2011-05-13 10:28       ` Johannes Weiner
2011-05-13 11:02       ` Michal Hocko
2011-05-13 11:02         ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 4/6] memcg: reclaim statistics Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 19:33   ` Ying Han
2011-05-16 23:10     ` Johannes Weiner
2011-05-16 23:10       ` Johannes Weiner
2011-05-17  0:20       ` Ying Han
2011-05-17  7:42         ` Johannes Weiner
2011-05-17  7:42           ` Johannes Weiner
2011-05-17 13:55           ` Rik van Riel
2011-05-17 13:55             ` Rik van Riel
2011-05-12 14:53 ` [rfc patch 5/6] memcg: remove global LRU list Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-13  9:53   ` Michal Hocko
2011-05-13  9:53     ` Michal Hocko
2011-05-13 10:36     ` Johannes Weiner
2011-05-13 10:36       ` Johannes Weiner
2011-05-13 11:01       ` Michal Hocko
2011-05-13 11:01         ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 6/6] memcg: rework soft limit reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 18:41   ` Ying Han
2011-05-12 18:41     ` Ying Han
2011-05-12 18:53 ` [rfc patch 0/6] mm: memcg naturalization Ying Han
2011-05-13  7:20   ` Johannes Weiner
2011-05-13  7:20     ` Johannes Weiner
2011-05-17  0:53     ` Ying Han
2011-05-17  8:11       ` Johannes Weiner
2011-05-17  8:11         ` Johannes Weiner
2011-05-17 14:45         ` Ying Han
2011-05-16 10:30 ` Balbir Singh
2011-05-16 10:30   ` Balbir Singh
2011-05-16 10:57   ` Johannes Weiner
2011-05-16 10:57     ` Johannes Weiner
2011-05-17  6:32     ` Balbir Singh
2011-05-17  6:32       ` Balbir Singh

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=20110512160349.GJ16531@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=minchan.kim@gmail.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=riel@redhat.com \
    --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.