[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2aee7e6b9096556aab9b47156e91082c9345a90.camel@gmx.de>
Date: Tue, 30 Nov 2021 18:59:58 +0100
From: Mike Galbraith <efault@....de>
To: Mel Gorman <mgorman@...hsingularity.net>,
Alexey Avramov <hakavlad@...ox.lv>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Vlastimil Babka <vbabka@...e.cz>,
Rik van Riel <riel@...riel.com>,
Darrick Wong <djwong@...nel.org>, regressions@...ts.linux.dev,
Linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] mm: vmscan: Reduce throttling due to a failure to
make progress
On Tue, 2021-11-30 at 17:27 +0000, Mel Gorman wrote:
>
> Obviously a fairly different experience and most likely due to the
> underlying storage.
I bet a virtual nickle this is the sore spot.
---
mm/vmscan.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3360,7 +3360,17 @@ static void shrink_node(pg_data_t *pgdat
if (!current_is_kswapd() && current_may_throttle() &&
!sc->hibernation_mode &&
test_bit(LRUVEC_CONGESTED, &target_lruvec->flags))
+#if 0
reclaim_throttle(pgdat, VMSCAN_THROTTLE_WRITEBACK);
+#else
+ /*
+ * wait_iff_congested() used to live here and was
+ * _apparently_ a misspelled cond_resched()?????
+ * In any case, we are most definitely NOT starting
+ * any IO in reclaim_throttle(), so why bother?
+ */
+ cond_resched();
+#endif
if (should_continue_reclaim(pgdat, sc->nr_reclaimed -
nr_reclaimed,
sc))
Powered by blists - more mailing lists