From: Mel Gorman <mgorman@suse.de>
To: Ying Han <yinghan@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
Hugh Dickins <hughd@google.com>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Removal of lumpy reclaim V2
Date: Thu, 12 Apr 2012 06:49:23 +0100 [thread overview]
Message-ID: <20120412054923.GL3789@suse.de> (raw)
In-Reply-To: <CALWz4iyt94KdRXTwr07+s5TPYtcwBX7xScQcqUvwVCnDMLH_TA@mail.gmail.com>
On Wed, Apr 11, 2012 at 04:37:00PM -0700, Ying Han wrote:
> > In 3.2, kswapd was doing a bunch of async writes of pages but
> > reclaim/compaction was never reaching a point where it was doing sync
> > IO. This does not guarantee that reclaim/compaction was not calling
> > wait_on_page_writeback() but I would consider it unlikely. It indicates
> > that merging patches 2 and 3 to stop reclaim/compaction calling
> > wait_on_page_writeback() should be safe.
> >
> > include/trace/events/vmscan.h | 40 ++-----
> > mm/vmscan.c | 263 ++++-------------------------------------
> > 2 files changed, 37 insertions(+), 266 deletions(-)
> >
> > --
> > 1.7.9.2
> >
>
> It might be a naive question, what we do w/ users with the following
> in the .config file?
>
> # CONFIG_COMPACTION is not set
>
After lumpy reclaim is removed page reclaim will be reclaiming at order-0
randomly to see if that frees up a high-order page randomly. It remains to
be seen how many users really depended on lumpy reclaim like this and as
to why they were not using compaction. Two configurations that may care are
NOMMU and SLUB. NOMMU may not notice as they were already unable to handle
anonymous pages in lumpy reclaim. SLUB will fallback to using order-0 pages.
--
Mel Gorman
SUSE Labs
--
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:[~2012-04-12 5:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 16:38 [PATCH 0/3] Removal of lumpy reclaim V2 Mel Gorman
2012-04-11 16:38 ` [PATCH 1/3] mm: vmscan: Remove lumpy reclaim Mel Gorman
2012-04-11 17:25 ` Rik van Riel
2012-04-11 18:54 ` KOSAKI Motohiro
2012-04-11 16:38 ` [PATCH 2/3] mm: vmscan: Do not stall on writeback during memory compaction Mel Gorman
2012-04-11 17:26 ` Rik van Riel
2012-04-11 18:51 ` KOSAKI Motohiro
2012-04-11 16:38 ` [PATCH 3/3] mm: vmscan: Remove reclaim_mode_t Mel Gorman
2012-04-11 17:26 ` Rik van Riel
2012-04-11 19:48 ` KOSAKI Motohiro
2012-04-11 17:17 ` [PATCH 0/3] Removal of lumpy reclaim V2 Rik van Riel
2012-04-11 17:52 ` Mel Gorman
2012-04-11 18:06 ` Rik van Riel
2012-04-12 9:32 ` Mel Gorman
2012-04-11 23:37 ` Ying Han
2012-04-12 5:49 ` Mel Gorman [this message]
2012-04-11 23:54 ` Hugh Dickins
2012-04-12 5:44 ` Mel Gorman
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=20120412054923.GL3789@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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;
as well as URLs for NNTP newsgroup(s).