From nobody Mon Apr 6 15:27:42 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 CC4A239B949 for ; Thu, 2 Apr 2026 18:53:41 +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=1775156021; cv=none; b=qj3I+6fQ9Pecra//LuQ/9PpOh9JgWL+ImUewgddxQQRGO37l+rQjyRyddLYQeU5IoaTrVRJyu+EV96dbOgXzCq9h7fsYKVzCCZyPFTJBkxgPbu92lLJcI1/krfHSdPz5DnBHP2YYQrHtxMPYnkdkEUrbr+gYfe8b37oSD7VuVFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775156021; c=relaxed/simple; bh=EATGoxb144ySghfszsyByP5U86/ZHl8CVCI8i+wfQTE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=s+TVkOtM5j9zOYQ0kIlShpkx/URTqJpLmEATR5D7ndvyCph9F+P+EZGcMtQx7kGzLxYgKm1oB9CnjCbniCIWufPxYNgdVYxwJwF+1rwryNfFXGBD+Zzgvq462318ClsVw4m9LBQ7L/02d7n3bADBzMoKFcADBu7ASTjV+YGy9Kg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sPchXNEV; 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="sPchXNEV" Received: by smtp.kernel.org (Postfix) with ESMTPS id 9C56FC2BCFB; Thu, 2 Apr 2026 18:53:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775156021; bh=EATGoxb144ySghfszsyByP5U86/ZHl8CVCI8i+wfQTE=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=sPchXNEVBkAynbKsWBA0BhCbH+FoYVVoxz3JSWFEi+VIlKhfjAyFjmsRAYzNFpOhY 8cPS6Ou/23phVRazFFz1ELEmlc5TsaELxyGghrtTafZ+3QZcEg9ly9NzExOQdoFOVV KghmwhzkXAIs+Jk+Oruxxm8d6L7LTO6BjmU9gqIO/LzmbVvRBtXleWsr2QPrkZh6Gq tbgSOl8qe06t9Zdhw+uh77i0oAz7uYE/lm+KZ3FHXlTjktVDaPzhl4TCqPmSnFO2dy vg0aOIpzNiLYnP17gjFCtgYqsnspkmm46XMGR333krO9k5e6dJSx/VUeRbQBFY3vUh ZEKnu0A+w5Vbw== 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 911EFD6AAFD; Thu, 2 Apr 2026 18:53:41 +0000 (UTC) From: Kairui Song via B4 Relay Date: Fri, 03 Apr 2026 02:53:33 +0800 Subject: [PATCH v3 07/14] 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: <20260403-mglru-reclaim-v3-7-a285efd6ff91@tencent.com> References: <20260403-mglru-reclaim-v3-0-a285efd6ff91@tencent.com> In-Reply-To: <20260403-mglru-reclaim-v3-0-a285efd6ff91@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.1 X-Developer-Signature: v=1; a=ed25519-sha256; t=1775156018; l=3449; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=bSy2f/NXeY/jTEGjpMc5skrp7OityVUKdYtvXUwM9i8=; b=QnCc+Y5vPX1EtMTnDjPqM98CZyYXa7TzJ9o1gvPr99U5A7mK5FSBlop3VqXGnX99Bxl5JRVJd 4OapmGaqoHAA3OGBA0cf2x/09kPXxW6LXW+v/C+H3lSS/MVsGNiepHl 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 9c28afb0219c..b3371877762a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4987,7 +4987,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); @@ -5005,7 +5005,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); @@ -5016,6 +5016,10 @@ static bool try_to_shrink_lruvec(struct lruvec *lruv= ec, struct scan_control *sc) if (should_abort_scan(lruvec, sc)) break; =20 + /* For cgroup reclaim, fairness is handled by iterator, not rotation */ + if (root_reclaim(sc) && should_age) + break; + nr_to_scan -=3D delta; cond_resched(); } --=20 2.53.0