[RFC PATCH v2 2/5] mm/vmscan: silence spurious max_seq race warning

[Ehab Ababneh]

When kswapd support is expanded to multiple threads per node, concurrent
aging becomes more likely and try_to_inc_max_seq() can lose a race to
another aging pass that has already advanced max_seq. That is benign and
not a bug, so drop the WARN_ON_ONCE that fires on it.

Do not change the returned success value in this case: a lost race still
means *this* call performed no eviction-enabling work, and get_nr_to_scan()
relies on that to decide whether to keep scanning this lruvec. Treating a
lost race as success caused threads to bail out of reclaim early under
contention, cutting reclaim throughput and leading to OOM kills under
sustained memory pressure (e.g. the Cassandra benchmark).

Signed-off-by: Ehab Ababneh <ehab.ababneh@xxxxxxxxx>
(cherry picked from commit e14f205c5114bf2e9b13a733c71eb3372a1ba531)
---
 mm/vmscan.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 37ce6860c215..107011f51fef 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4116,10 +4116,8 @@ static bool try_to_inc_max_seq(struct lruvec *lruvec, unsigned long seq,
 			walk_mm(mm, walk);
 	} while (mm);
 done:
-	if (success) {
+	if (success)
 		success = inc_max_seq(lruvec, seq, swappiness);
-		WARN_ON_ONCE(!success);
-	}
 
 	return success;
 }
-- 
2.43.0