From nobody Thu Apr 2 14:13:10 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB8FC33F8B2 for ; Sat, 28 Mar 2026 19:52:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774727551; cv=none; b=irxUqkCKLOGuHIagls9OlwpGWqTVPmBZeCK74O2fHbIoKfB3rQkbBGT8zPzI2laJwsY/PQVzBMPGgttgSFTnnf6Ob5alHHXSjwfhavWfvsXx2P294v/YjQda1/QberqttY21tTav3PjeosOBuKRBLY46VMxcDsWmWlOEAAZYHw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774727551; c=relaxed/simple; bh=sECggSc4MF397YOh2/Lacxd/o6F18d1Kk6r+68wxb0c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=OgbYXa9kHDEpEGShEgn+nB8fBE33UyGB+Oe44sEgQQJh1YanRMMpSsxr8UI5eZfN2UCp4rwy4A6qTm83cUffcHdbqji+xQ4X+JN6u5mIiqbdr/ihYY92T+IAukqto4gyF2gTBmWvwtJBvvbhb839TJOnm2TwN11gtj36f+dveTA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nb8ZGWPx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nb8ZGWPx" Received: by smtp.kernel.org (Postfix) with ESMTPS id 9B06BC2BCC7; Sat, 28 Mar 2026 19:52:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774727551; bh=sECggSc4MF397YOh2/Lacxd/o6F18d1Kk6r+68wxb0c=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=nb8ZGWPxqEDG1L38yQLEuAsDALo+VfAOYJ51C++dgxiFRhcLKT0KqtAzF+XN32/U+ gdGDKRAi8FzcUMCKep823Do35smfmRUJIY5sHImNpIUcGr2gRZN5KVw2M3ZQj5EjaK Xef56XKRGGJJokBhwXIuXc/x12SAUxHvIpBq5Z/3xDUJGIDkktL95xWI7hNsjyhkmu Yvj1ihHKvuf2yRiYWIcimIK097E/QNCf5l6HIiitSzI1OlwK/guRXMD05Nw7LrJwKJ BjvEIDFOlDpB8HNQelOs8xrST9cYbQu1ChbRLk0ijyA1ukfrXUk3SFw6IXzyfHmaY7 /jJ/YXWNilpLg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91FB710F3DFB; Sat, 28 Mar 2026 19:52:31 +0000 (UTC) From: Kairui Song via B4 Relay Date: Sun, 29 Mar 2026 03:52:33 +0800 Subject: [PATCH v2 07/12] mm/mglru: don't abort scan immediately right after aging Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260329-mglru-reclaim-v2-7-b53a3678513c@tencent.com> References: <20260329-mglru-reclaim-v2-0-b53a3678513c@tencent.com> In-Reply-To: <20260329-mglru-reclaim-v2-0-b53a3678513c@tencent.com> To: linux-mm@kvack.org Cc: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org, Qi Zheng , Baolin Wang , Kairui Song X-Mailer: b4 0.15.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1774727549; l=3429; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=9oXAEtsd+KkctSkA6zzJc0gY6moW3RMhiz1U6qfN0UQ=; b=HN9WBP30sd3hrrKuJwKAHlFAFwvd6vODwGA7Eb826xhii9eEYNqDL5i6qLjQoXwZiXYh4GCih gJOM6K37lHQBG45xgdCcGR0ja9EsZn5g1O7FPgsTxAE+5vYFcjRnzgE X-Developer-Key: i=kasong@tencent.com; a=ed25519; pk=kCdoBuwrYph+KrkJnrr7Sm1pwwhGDdZKcKrqiK8Y1mI= X-Endpoint-Received: by B4 Relay for kasong@tencent.com/kasong-sign-tencent with auth_id=562 X-Original-From: Kairui Song Reply-To: kasong@tencent.com From: Kairui Song Right now, if eviction triggers aging, the reclaimer will abort. This is not the optimal strategy for several reasons. Aborting the reclaim early wastes a reclaim cycle when under pressure, and for concurrent reclaim, if the LRU is under aging, all concurrent reclaimers might fail. And if the age has just finished, new cold folios exposed by the aging are not reclaimed until the next reclaim iteration. What's more, the current aging trigger is quite lenient, having 3 gens with a reclaim priority lower than default will trigger aging, and blocks reclaiming from one memcg. This wastes reclaim retry cycles easily. And in the worst case, if the reclaim is making slower progress and all following attempts fail due to being blocked by aging, it triggers unexpected early OOM. And if a lruvec requires aging, it doesn't mean it's hot. Instead, the lruvec could be idle for quite a while, and hence it might contain lots of cold folios to be reclaimed. While it's helpful to rotate memcg LRU after aging for global reclaim, as global reclaim fairness is coupled with the rotation in shrink_many, memcg fairness is instead handled by cgroup iteration in shrink_node_memcgs. So, for memcg level pressure, this abort is not the key part for keeping the fairness. And in most cases, there is no need to age, and fairness must be achieved by upper-level reclaim control. So instead, just keep the scanning going unless one whole batch of folios failed to be isolated or enough folios have been scanned, which is triggered by evict_folios returning 0. And only abort for global reclaim after one batch, so when there are fewer memcgs, progress is still made, and the fairness mechanism described above still works fine. And in most cases, the one more batch attempt for global reclaim might just be enough to satisfy what the reclaimer needs, hence improving global reclaim performance by reducing reclaim retry cycles. Rotation is still there after the reclaim is done, which still follows the comment in mmzone.h. And fairness still looking good. Signed-off-by: Kairui Song --- mm/vmscan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index e3ca38d0c4cd..8de5c8d5849e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4983,7 +4983,7 @@ static bool should_abort_scan(struct lruvec *lruvec, = struct scan_control *sc) */ static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_contro= l *sc) { - bool need_rotate =3D false; + bool need_rotate =3D false, should_age =3D false; long nr_batch, nr_to_scan; int swappiness =3D get_swappiness(lruvec, sc); struct mem_cgroup *memcg =3D lruvec_memcg(lruvec); @@ -5001,7 +5001,7 @@ static bool try_to_shrink_lruvec(struct lruvec *lruve= c, struct scan_control *sc) if (should_run_aging(lruvec, max_seq, sc, swappiness)) { if (try_to_inc_max_seq(lruvec, max_seq, swappiness, false)) need_rotate =3D true; - break; + should_age =3D true; } =20 nr_batch =3D min(nr_to_scan, MIN_LRU_BATCH); @@ -5012,6 +5012,10 @@ static bool try_to_shrink_lruvec(struct lruvec *lruv= ec, struct scan_control *sc) if (should_abort_scan(lruvec, sc)) break; =20 + /* Cgroup reclaim fairness not guarded by rotate */ + if (root_reclaim(sc) && should_age) + break; + nr_to_scan -=3D delta; cond_resched(); } --=20 2.53.0