Re: [PATCH 1/1] mm: vmscan: Reduce throttling due to a failure to make progress

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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))





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux