From: Johannes Weiner <hannes@cmpxchg.org>
To: Ying Han <yinghan@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Michal Hocko <mhocko@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
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 3/6] mm: memcg-aware global reclaim
Date: Fri, 13 May 2011 09:08:39 +0200 [thread overview]
Message-ID: <20110513070839.GC18610@cmpxchg.org> (raw)
In-Reply-To: <BANLkTimr1sCLTa2JuMUYUFQWGS2D8c9GEA@mail.gmail.com>
On Thu, May 12, 2011 at 12:19:45PM -0700, Ying Han wrote:
> On Thu, May 12, 2011 at 7:53 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > A page charged to a memcg is linked to a lru list specific to that
> > memcg. At the same time, traditional global reclaim is obvlivious to
> > memcgs, and all the pages are also linked to a global per-zone list.
> >
> > This patch changes traditional global reclaim to iterate over all
> > existing memcgs, so that it no longer relies on the global list being
> > present.
> >
>
> > This is one step forward in integrating memcg code better into the
> > rest of memory management. It is also a prerequisite to get rid
> > of the global per-zone lru lists.
> >
> Sorry If i misunderstood something here. I assume this patch has not
> much to do with the global soft_limit reclaim, but only allow the
> system only scan per-memcg lru under global memory pressure.
I see you found 6/6 in the meantime :) Did it answer your question?
> > The algorithm implemented in this patch is very naive. For each zone
> > scanned at each priority level, it iterates over all existing memcgs
> > and considers them for scanning.
> >
> > This is just a prototype and I did not optimize it yet because I am
> > unsure about the maximum number of memcgs that still constitute a sane
> > configuration in comparison to the machine size.
>
> So we also scan memcg which has no page allocated on this zone? I
> will read the following patch in case i missed something here :)
The old hierarchy walk skipped a memcg if it had no local pages at
all. I thought this was a rather unlikely situation and ripped it
out.
It will not loop persistently over a specific memcg and node
combination, like soft limit reclaim does at the moment.
Since this is much deeper integrated in memory reclaim now, it
benefits from all the existing mechanisms and will calculate the scan
target based on the number of lru pages on memcg->zone->lru, and do
nothing if there are no pages there.
--
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>
next prev parent reply other threads:[~2011-05-13 7:08 UTC|newest]
Thread overview: 45+ 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 ` [rfc patch 1/6] memcg: remove unused retry signal from reclaim Johannes Weiner
2011-05-12 15:02 ` Rik van Riel
2011-05-12 17:22 ` Ying Han
2011-05-12 23:44 ` KAMEZAWA Hiroyuki
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 15:33 ` Rik van Riel
2011-05-12 16:03 ` Johannes Weiner
2011-05-17 6:38 ` Ying Han
2011-05-17 8:25 ` Johannes Weiner
2011-05-12 23:50 ` KAMEZAWA Hiroyuki
2011-05-13 6:58 ` Johannes Weiner
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 16:04 ` Rik van Riel
2011-05-12 19:19 ` Ying Han
2011-05-13 7:08 ` Johannes Weiner [this message]
2011-05-13 0:04 ` KAMEZAWA Hiroyuki
2011-05-13 7:18 ` Johannes Weiner
2011-05-13 0:40 ` KAMEZAWA Hiroyuki
2011-05-13 6:54 ` Johannes Weiner
2011-05-13 9:53 ` Michal Hocko
2011-05-13 10:28 ` Johannes Weiner
2011-05-13 11:02 ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 4/6] memcg: reclaim statistics Johannes Weiner
2011-05-12 19:33 ` Ying Han
2011-05-16 23:10 ` Johannes Weiner
2011-05-17 0:20 ` Ying Han
2011-05-17 7:42 ` Johannes Weiner
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-13 9:53 ` Michal Hocko
2011-05-13 10:36 ` Johannes Weiner
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 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-17 0:53 ` Ying Han
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:57 ` Johannes Weiner
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=20110513070839.GC18610@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox