From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com
Subject: Re: [PATCH 2/5] mm: vmscan: kick flushers when we encounter dirty pages on the LRU
Date: Thu, 26 Jan 2017 12:47:39 -0500 [thread overview]
Message-ID: <20170126174739.GA30636@cmpxchg.org> (raw)
In-Reply-To: <20170126095745.ueigbrsop5vgmwzj@suse.de>
On Thu, Jan 26, 2017 at 09:57:45AM +0000, Mel Gorman wrote:
> On Mon, Jan 23, 2017 at 01:16:38PM -0500, Johannes Weiner wrote:
> > Memory pressure can put dirty pages at the end of the LRU without
> > anybody running into dirty limits. Don't start writing individual
> > pages from kswapd while the flushers might be asleep.
> >
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> I don't understand the motivation for checking the wb_reason name. Maybe
> it was easier to eyeball while reading ftraces. The comment about the
> flusher not doing its job could also be as simple as the writes took
> place and clean pages were reclaimed before dirty_expire was reached.
> Not impossible if there was a light writer combined with a heavy reader
> or a large number of anonymous faults.
The name change was only because try_to_free_pages() wasn't the only
function doing this flusher wakeup anymore. I associate that name with
direct reclaim rather than reclaim in general, so I figured this makes
more sense. No strong feelings either way, but I doubt this will break
anything in userspace.
The comment on dirty expiration is a good point. Let's add this to the
list of reasons why reclaim might run into dirty data. Fixlet below.
> Acked-by: Mel Gorman <mgorman@suse.de>
Thanks!
---
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com
Subject: Re: [PATCH 2/5] mm: vmscan: kick flushers when we encounter dirty pages on the LRU
Date: Thu, 26 Jan 2017 12:47:39 -0500 [thread overview]
Message-ID: <20170126174739.GA30636@cmpxchg.org> (raw)
In-Reply-To: <20170126095745.ueigbrsop5vgmwzj@suse.de>
On Thu, Jan 26, 2017 at 09:57:45AM +0000, Mel Gorman wrote:
> On Mon, Jan 23, 2017 at 01:16:38PM -0500, Johannes Weiner wrote:
> > Memory pressure can put dirty pages at the end of the LRU without
> > anybody running into dirty limits. Don't start writing individual
> > pages from kswapd while the flushers might be asleep.
> >
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> I don't understand the motivation for checking the wb_reason name. Maybe
> it was easier to eyeball while reading ftraces. The comment about the
> flusher not doing its job could also be as simple as the writes took
> place and clean pages were reclaimed before dirty_expire was reached.
> Not impossible if there was a light writer combined with a heavy reader
> or a large number of anonymous faults.
The name change was only because try_to_free_pages() wasn't the only
function doing this flusher wakeup anymore. I associate that name with
direct reclaim rather than reclaim in general, so I figured this makes
more sense. No strong feelings either way, but I doubt this will break
anything in userspace.
The comment on dirty expiration is a good point. Let's add this to the
list of reasons why reclaim might run into dirty data. Fixlet below.
> Acked-by: Mel Gorman <mgorman@suse.de>
Thanks!
---
>From 44c4289ab85c0af66cb06de6d1bb72a5c67fd755 Mon Sep 17 00:00:00 2001
From: Johannes Weiner <hannes@cmpxchg.org>
Date: Thu, 26 Jan 2017 12:41:39 -0500
Subject: [PATCH] mm: vmscan: kick flushers when we encounter dirty pages on
the LRU fix
Mention dirty expiration as a condition: we need dirty data that is
too recent for periodic flushing and not large enough for waking up
limit flushing. As per Mel.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/vmscan.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 56ea8d24041f..ccd4bf952cb3 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1799,15 +1799,14 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
/*
* If dirty pages are scanned that are not queued for IO, it
* implies that flushers are not doing their job. This can
- * happen when memory pressure pushes dirty pages to the end
- * of the LRU without the dirty limits being breached. It can
- * also happen when the proportion of dirty pages grows not
- * through writes but through memory pressure reclaiming all
- * the clean cache. And in some cases, the flushers simply
- * cannot keep up with the allocation rate. Nudge the flusher
- * threads in case they are asleep, but also allow kswapd to
- * start writing pages during reclaim.
+ * happen when memory pressure pushes dirty pages to the end of
+ * the LRU before the dirty limits are breached and the dirty
+ * data has expired. It can also happen when the proportion of
+ * dirty pages grows not through writes but through memory
+ * pressure reclaiming all the clean cache. And in some cases,
+ * the flushers simply cannot keep up with the allocation
+ * rate. Nudge the flusher threads in case they are asleep, but
+ * also allow kswapd to start writing pages during reclaim.
*/
if (stat.nr_unqueued_dirty == nr_taken) {
wakeup_flusher_threads(0, WB_REASON_VMSCAN);
--
2.11.0
next prev parent reply other threads:[~2017-01-26 17: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 [this message]
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
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=20170126174739.GA30636@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.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.