All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH 5/5] mm: vmscan: move dirty pages out of the way until they're flushed
Date: Thu, 26 Jan 2017 10:47:36 +0900	[thread overview]
Message-ID: <20170126014736.GE21211@bbox> (raw)
In-Reply-To: <20170123181641.23938-6-hannes@cmpxchg.org>

On Mon, Jan 23, 2017 at 01:16:41PM -0500, Johannes Weiner wrote:
> We noticed a performance regression when moving hadoop workloads from
> 3.10 kernels to 4.0 and 4.6. This is accompanied by increased pageout
> activity initiated by kswapd as well as frequent bursts of allocation
> stalls and direct reclaim scans. Even lowering the dirty ratios to the
> equivalent of less than 1% of memory would not eliminate the issue,
> suggesting that dirty pages concentrate where the scanner is looking.
> 
> This can be traced back to recent efforts of thrash avoidance. Where
> 3.10 would not detect refaulting pages and continuously supply clean
> cache to the inactive list, a thrashing workload on 4.0+ will detect
> and activate refaulting pages right away, distilling used-once pages
> on the inactive list much more effectively. This is by design, and it
> makes sense for clean cache. But for the most part our workload's
> cache faults are refaults and its use-once cache is from streaming
> writes. We end up with most of the inactive list dirty, and we don't
> go after the active cache as long as we have use-once pages around.
> 
> But waiting for writes to avoid reclaiming clean cache that *might*
> refault is a bad trade-off. Even if the refaults happen, reads are
> faster than writes. Before getting bogged down on writeback, reclaim
> should first look at *all* cache in the system, even active cache.
> 
> To accomplish this, activate pages that have been dirty or under
> writeback for two inactive LRU cycles. We know at this point that
> there are not enough clean inactive pages left to satisfy memory
> demand in the system. The pages are marked for immediate reclaim,
> meaning they'll get moved back to the inactive LRU tail as soon as
> they're written back and become reclaimable. But in the meantime, by
> reducing the inactive list to only immediately reclaimable pages, we
> allow the scanner to deactivate and refill the inactive list with
> clean cache from the active list tail to guarantee forward progress.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Minchan Kim <minchan@kernel.org>

Every patches look reasaonable to me.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH 5/5] mm: vmscan: move dirty pages out of the way until they're flushed
Date: Thu, 26 Jan 2017 10:47:36 +0900	[thread overview]
Message-ID: <20170126014736.GE21211@bbox> (raw)
In-Reply-To: <20170123181641.23938-6-hannes@cmpxchg.org>

On Mon, Jan 23, 2017 at 01:16:41PM -0500, Johannes Weiner wrote:
> We noticed a performance regression when moving hadoop workloads from
> 3.10 kernels to 4.0 and 4.6. This is accompanied by increased pageout
> activity initiated by kswapd as well as frequent bursts of allocation
> stalls and direct reclaim scans. Even lowering the dirty ratios to the
> equivalent of less than 1% of memory would not eliminate the issue,
> suggesting that dirty pages concentrate where the scanner is looking.
> 
> This can be traced back to recent efforts of thrash avoidance. Where
> 3.10 would not detect refaulting pages and continuously supply clean
> cache to the inactive list, a thrashing workload on 4.0+ will detect
> and activate refaulting pages right away, distilling used-once pages
> on the inactive list much more effectively. This is by design, and it
> makes sense for clean cache. But for the most part our workload's
> cache faults are refaults and its use-once cache is from streaming
> writes. We end up with most of the inactive list dirty, and we don't
> go after the active cache as long as we have use-once pages around.
> 
> But waiting for writes to avoid reclaiming clean cache that *might*
> refault is a bad trade-off. Even if the refaults happen, reads are
> faster than writes. Before getting bogged down on writeback, reclaim
> should first look at *all* cache in the system, even active cache.
> 
> To accomplish this, activate pages that have been dirty or under
> writeback for two inactive LRU cycles. We know at this point that
> there are not enough clean inactive pages left to satisfy memory
> demand in the system. The pages are marked for immediate reclaim,
> meaning they'll get moved back to the inactive LRU tail as soon as
> they're written back and become reclaimable. But in the meantime, by
> reducing the inactive list to only immediately reclaimable pages, we
> allow the scanner to deactivate and refill the inactive list with
> clean cache from the active list tail to guarantee forward progress.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Minchan Kim <minchan@kernel.org>

Every patches look reasaonable to me.

  reply	other threads:[~2017-01-26  1:47 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23 18:16 [PATCH 0/5] mm: vmscan: fix kswapd writeback regression Johannes Weiner
2017-01-23 18:16 ` Johannes Weiner
2017-01-23 18:16 ` [PATCH 1/5] mm: vmscan: scan dirty pages even in laptop mode Johannes Weiner
2017-01-23 18:16   ` Johannes Weiner
2017-01-26  1:27   ` Minchan Kim
2017-01-26  1:27     ` Minchan Kim
2017-01-26  9:52   ` Mel Gorman
2017-01-26  9:52     ` Mel Gorman
2017-01-26 13:13   ` Michal Hocko
2017-01-26 13:13     ` Michal Hocko
2017-01-23 18:16 ` [PATCH 2/5] mm: vmscan: kick flushers when we encounter dirty pages on the LRU Johannes Weiner
2017-01-23 18:16   ` Johannes Weiner
2017-01-26  1:35   ` Minchan Kim
2017-01-26  1:35     ` Minchan Kim
2017-01-26  9:57   ` Mel Gorman
2017-01-26  9:57     ` Mel Gorman
2017-01-26 17:47     ` Johannes Weiner
2017-01-26 17:47       ` Johannes Weiner
2017-01-26 18:47       ` Mel Gorman
2017-01-26 18:47         ` Mel Gorman
2017-01-26 13:16   ` Michal Hocko
2017-01-26 13:16     ` Michal Hocko
2017-01-23 18:16 ` [PATCH 3/5] mm: vmscan: remove old flusher wakeup from direct reclaim path Johannes Weiner
2017-01-23 18:16   ` Johannes Weiner
2017-01-26  1:38   ` Minchan Kim
2017-01-26  1:38     ` Minchan Kim
2017-01-26 10:05   ` Mel Gorman
2017-01-26 10:05     ` Mel Gorman
2017-01-26 18:50     ` Johannes Weiner
2017-01-26 18:50       ` Johannes Weiner
2017-01-26 20:45       ` Mel Gorman
2017-01-26 20:45         ` Mel Gorman
2017-01-27 12:01       ` Michal Hocko
2017-01-27 12:01         ` Michal Hocko
2017-01-27 14:27         ` Mel Gorman
2017-01-27 14:27           ` Mel Gorman
2017-01-26 13:21   ` Michal Hocko
2017-01-26 13:21     ` Michal Hocko
2017-01-23 18:16 ` [PATCH 4/5] mm: vmscan: only write dirty pages that the scanner has seen twice Johannes Weiner
2017-01-23 18:16   ` Johannes Weiner
2017-01-26  1:42   ` Minchan Kim
2017-01-26  1:42     ` Minchan Kim
2017-01-26 10:08   ` Mel Gorman
2017-01-26 10:08     ` Mel Gorman
2017-01-26 13:29   ` Michal Hocko
2017-01-26 13:29     ` Michal Hocko
2017-01-23 18:16 ` [PATCH 5/5] mm: vmscan: move dirty pages out of the way until they're flushed Johannes Weiner
2017-01-23 18:16   ` Johannes Weiner
2017-01-26  1:47   ` Minchan Kim [this message]
2017-01-26  1:47     ` Minchan Kim
2017-01-26 10:19   ` Mel Gorman
2017-01-26 10:19     ` Mel Gorman
2017-01-26 20:07     ` Johannes Weiner
2017-01-26 20:07       ` Johannes Weiner
2017-01-26 20:58       ` Mel Gorman
2017-01-26 20:58         ` Mel Gorman
2017-01-26 13:52   ` Michal Hocko
2017-01-26 13:52     ` Michal Hocko
2017-01-26  5:44 ` [PATCH 0/5] mm: vmscan: fix kswapd writeback regression Hillf Danton
2017-01-26  5:44   ` Hillf Danton

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=20170126014736.GE21211@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.