mm:vmscan: fix shrink sc->nr.immediate counter issue

Commit Message

zhiguojiang Nov. 30, 2023, 2:45 a.m. UTC

It can't be guaranteed for the PGDAT_WRITEBACK flag that there is only
one type of page marked for immediate reclaim on evictable LRUs in the
following shrink processes of the same kswapd shrink recycling. So for
the siuation that if there are only a small number of pages or even only
one page marked for immediate reclaim on evictable LRUs, and at the same
time there are a large number of pages unmarked for immediate reclaim on
evictable LRUs, kswapd is also throttled, which will increase kswapd
shrink consumption.

It can be fixed to throttle kswapd shrink when sc->nr.immediate is equal
to sc->nr.file_taken. And when there are both pages marked and unmarked
for immediate reclaim on evictable LRUs at the same time, kswapd will be
not throttled, and kswapd will first reclaim pages unmarked for immediate
reclaim on evictable LRUs quickly.

Signed-off-by: Zhiguo Jiang <[e-mail]>
---
 mm/vmscan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 mm/vmscan.c

Patch

diff --git a/mm/vmscan.c b/mm/vmscan.c
index d8c3338fee0f..af2b6906171a
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -5919,13 +5919,13 @@  static void shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 			set_bit(PGDAT_DIRTY, &pgdat->flags);
 
 		/*
-		 * If kswapd scans pages marked for immediate
+		 * If kswapd scans massive pages marked for immediate
 		 * reclaim and under writeback (nr_immediate), it
 		 * implies that pages are cycling through the LRU
 		 * faster than they are written so forcibly stall
 		 * until some pages complete writeback.
 		 */
-		if (sc->nr.immediate)
+		if (sc->nr.immediate && sc->nr.immediate == sc->nr.file_taken)
 			reclaim_throttle(pgdat, VMSCAN_THROTTLE_WRITEBACK);
 	}