From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (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 499FA3ACA57 for ; Mon, 30 Mar 2026 08:15:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774858505; cv=none; b=Ng+0N1jImpit34d38hGh1KEiGTbT23OT6IiVYbI+e9i3uIIHPFRoPA74Xd895TYlVHD8DD1/lSbGoZeMb5m6+OWOPqAu4dXxnBUdr2gR3n5VO9jO7iPCELY6j6wAKb4HRuHBgVvOMipZLvLql3evzOEwUVRkg46VtFRca9hP+ww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774858505; c=relaxed/simple; bh=eaRGIgKRDvQHm2ThDf1Z16KVpNkiZE3x1/yrSNdIJ4s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dIbJsMdCpbtESgTLBTp42gkWRmi5xb4cXtG+RVkxisNUepkvw+2Y5TzcW9HnJDv3sAHevEQGaWU6QE9nui3QCJ/veHbT7gsvPn3wfjkKXRvQqK5YruX0e5p1F8gowSNXkwmZXq5Wh2VpfbdyMjzc77SPTTEalXqyjR/WpUon7kM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=uFXu2fhK; arc=none smtp.client-ip=115.124.30.110 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="uFXu2fhK" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774858498; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=TZODsN0thY0LoA5mBOTgwAZIPwWkd72oa5M0lRWn5DA=; b=uFXu2fhKMlHR5AjR7M/xWSOxyn7/mWnypK6c61rlHpwCNV4vgWE8GWjWTcpM1Fq1ePQBPMkCtw/XFhb/omci61mVnTEPq+cgpmfbxzsZckB9EgPRP7puZI1cAtB16hShIjnnh5sXZaaBH3+J5jRSNvG6BarERhHcE+30BDRPlAs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R641e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=25;SR=0;TI=SMTPD_---0X.x4OtT_1774858496; Received: from 30.74.144.120(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.x4OtT_1774858496 cluster:ay36) by smtp.aliyun-inc.com; Mon, 30 Mar 2026 16:14:56 +0800 Message-ID: <8150afe4-53ee-49ff-adfc-e29a483fd1f7@linux.alibaba.com> Date: Mon, 30 Mar 2026 16:14:55 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/12] mm/mglru: relocate the LRU scan batch limit to callers To: kasong@tencent.com, 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 References: <20260329-mglru-reclaim-v2-0-b53a3678513c@tencent.com> <20260329-mglru-reclaim-v2-3-b53a3678513c@tencent.com> From: Baolin Wang In-Reply-To: <20260329-mglru-reclaim-v2-3-b53a3678513c@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/29/26 3:52 AM, Kairui Song via B4 Relay wrote: > 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 > --- Some nits as follows, otherwise LGTM. Reviewed-by: Baolin Wang > 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, struct lruvec *lruvec, > int scanned = 0; > int isolated = 0; > int skipped = 0; > - int scan_batch = min(nr_to_scan, MAX_LRU_BATCH); > - int remaining = scan_batch; > + unsigned long remaining = nr_to_scan; > struct lru_gen_folio *lrugen = &lruvec->lrugen; > > + VM_WARN_ON_ONCE(nr_to_scan > MAX_LRU_BATCH); > VM_WARN_ON_ONCE(!list_empty(list)); > > if (get_nr_gens(lruvec, type) == MIN_NR_GENS) > @@ -4751,7 +4751,7 @@ static int scan_folios(unsigned long nr_to_scan, struct 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 == LRU_GEN_FILE) > @@ -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_control *sc) > { > - long nr_to_scan; > + long nr_batch, nr_to_scan; Nit: Since evict_folios() expects an unsgined long, why not define 'unsigned long nr_batch'? > unsigned long scanned = 0; > int swappiness = get_swappiness(lruvec, sc); > > @@ -4998,7 +4998,8 @@ static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > if (nr_to_scan <= 0) > break; > > - delta = evict_folios(nr_to_scan, lruvec, sc, swappiness); > + nr_batch = min(nr_to_scan, MAX_LRU_BATCH); > + delta = evict_folios(nr_batch, lruvec, sc, swappiness); > if (!delta) > break; > > @@ -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 scan_control *sc, > int swappiness, unsigned long nr_to_reclaim) > { > + int nr_batch; Nit: since 'nr_to_reclaim' is unsigned long, better to use unsigned long for 'nr_batch'. > DEFINE_MAX_SEQ(lruvec); > > if (seq + MIN_NR_GENS > max_seq) > @@ -5639,8 +5641,8 @@ static int run_eviction(struct lruvec *lruvec, unsigned long seq, struct scan_co > if (sc->nr_reclaimed >= nr_to_reclaim) > return 0; > > - if (!evict_folios(nr_to_reclaim - sc->nr_reclaimed, lruvec, sc, > - swappiness)) > + nr_batch = min(nr_to_reclaim - sc->nr_reclaimed, MAX_LRU_BATCH); > + if (!evict_folios(nr_batch, lruvec, sc, swappiness)) > return 0; > > cond_resched(); >