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 A73DC33BBB1 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=jZdWUZ4XbSotduEoTlZjsRKiSkHZs7wJ4Uacdx+hsFkJkAAnuBVpt5tLD7i+M2VUQvt+J4hTWkNGqp9zordZX0o4a2HC3dlsb6dtiJdhysTOEIl/zhcxKjCj2RgoB8dDSSdyGOoWiZLkXysyAPbQFFdOhcVWFUKBqZp58XP2k08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774727551; c=relaxed/simple; bh=V+u/1ghTYrgsgZAfHoL8/JWPdvg7AFyTZRkLhwRadE8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SMBOXDdvZI7/dnR3uJpNCegCqrmXLHBlPt+vSXsmX2AR2t3MR4XWVnFEZw5PyqaP/bn1pogPlv63XoL/P7oLsnFTUcXM7oQovVtl3/XWEE+zyPuifKMXEaugbo+Luw6IAePhyPPEOicKyhG3wF44QdfL493MzMwyIWdhxA/fe1k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHpOUNrF; 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="HHpOUNrF" Received: by smtp.kernel.org (Postfix) with ESMTPS id 5FA35C2BCB3; 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=V+u/1ghTYrgsgZAfHoL8/JWPdvg7AFyTZRkLhwRadE8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=HHpOUNrFFJaqCL69NLU86O/jJ9w2xAaAjGbTCQ7OdmuyyvOBCb6yI+HtYo3lgh0rD w2jFfUSnaapZr7GPScDbG41DXMpSSNbz9aen++HR4SbfqcVLzSX2X72fb45svUC70Y aouKEhNmuU1px3JbsChmNZ1lUc26NSKAfY8R+jXUd+0oFdb9hG42873XpEeYD8vfQn A/5n95vWQtWFMaTyGciGiTc33aUYLrQyFyEcsp/Q0W5AmtEash7RmQ453DsUPVmlzT ke3wwlzLBrHF+z1NdQKDJPc4PkQk0+Tik0aPNAJbvYwaFkgocG0AFjUeTC03IxfIss HTtn7HsjHIJbw== 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 4BC8D10F3DF8; Sat, 28 Mar 2026 19:52:31 +0000 (UTC) From: Kairui Song via B4 Relay Date: Sun, 29 Mar 2026 03:52:29 +0800 Subject: [PATCH v2 03/12] mm/mglru: relocate the LRU scan batch limit to callers 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-3-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=3157; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=4QFLBbTOMAuh+ZOeAXX+ybk8/f1xj2wdgM33A3nTdsE=; b=sb434GG68neBgavvN9RF+c/IZlt6aLeFt5v1BLAVw88W8kUhrfTWqgPklM9E2FF+SOStm/2tW g4HlPTF6IdBAKLmenUvKBiUiE5/2hi06XqPfY2dbZ+qyx02+g3i0r2m 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 Same as active / inactive LRU, MGLRU isolates and scans folios in batches. The batch split is done hidden deep in the helper, which makes the code harder to follow. The helper's arguments are also confusing since callers usually request more folios than the batch size, so the helper almost never processes the full requested amount. Move the batch splitting into the top loop to make it cleaner, there should be no behavior change. Reviewed-by: Axel Rasmussen Signed-off-by: Kairui Song Reviewed-by: Baolin Wang Reviewed-by: Barry Song --- mm/vmscan.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index f336f89a2de6..963362523782 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4695,10 +4695,10 @@ static int scan_folios(unsigned long nr_to_scan, st= ruct lruvec *lruvec, int scanned =3D 0; int isolated =3D 0; int skipped =3D 0; - int scan_batch =3D min(nr_to_scan, MAX_LRU_BATCH); - int remaining =3D scan_batch; + unsigned long remaining =3D nr_to_scan; struct lru_gen_folio *lrugen =3D &lruvec->lrugen; =20 + VM_WARN_ON_ONCE(nr_to_scan > MAX_LRU_BATCH); VM_WARN_ON_ONCE(!list_empty(list)); =20 if (get_nr_gens(lruvec, type) =3D=3D MIN_NR_GENS) @@ -4751,7 +4751,7 @@ static int scan_folios(unsigned long nr_to_scan, stru= ct lruvec *lruvec, mod_lruvec_state(lruvec, item, isolated); mod_lruvec_state(lruvec, PGREFILL, sorted); mod_lruvec_state(lruvec, PGSCAN_ANON + type, isolated); - trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, scan_batch, + trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scanned, skipped, isolated, type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON); if (type =3D=3D LRU_GEN_FILE) @@ -4987,7 +4987,7 @@ static bool should_abort_scan(struct lruvec *lruvec, = struct scan_control *sc) =20 static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_contro= l *sc) { - long nr_to_scan; + long nr_batch, nr_to_scan; unsigned long scanned =3D 0; int swappiness =3D get_swappiness(lruvec, sc); =20 @@ -4998,7 +4998,8 @@ static bool try_to_shrink_lruvec(struct lruvec *lruve= c, struct scan_control *sc) if (nr_to_scan <=3D 0) break; =20 - delta =3D evict_folios(nr_to_scan, lruvec, sc, swappiness); + nr_batch =3D min(nr_to_scan, MAX_LRU_BATCH); + delta =3D evict_folios(nr_batch, lruvec, sc, swappiness); if (!delta) break; =20 @@ -5623,6 +5624,7 @@ static int run_aging(struct lruvec *lruvec, unsigned = long seq, static int run_eviction(struct lruvec *lruvec, unsigned long seq, struct s= can_control *sc, int swappiness, unsigned long nr_to_reclaim) { + int nr_batch; DEFINE_MAX_SEQ(lruvec); =20 if (seq + MIN_NR_GENS > max_seq) @@ -5639,8 +5641,8 @@ static int run_eviction(struct lruvec *lruvec, unsign= ed long seq, struct scan_co if (sc->nr_reclaimed >=3D nr_to_reclaim) return 0; =20 - if (!evict_folios(nr_to_reclaim - sc->nr_reclaimed, lruvec, sc, - swappiness)) + nr_batch =3D min(nr_to_reclaim - sc->nr_reclaimed, MAX_LRU_BATCH); + if (!evict_folios(nr_batch, lruvec, sc, swappiness)) return 0; =20 cond_resched(); --=20 2.53.0