From mboxrd@z Thu Jan 1 00:00:00 1970 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 F306D3009D4 for ; Sat, 25 Apr 2026 20:58:07 +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=1777150688; cv=none; b=EEXt3D/GaX7NygOLHpcSOuGfh5DSGnwa9QFdyaixQA4ClODB5uxPSl4UdOLcwCEn/MDM8AXUivujlhySuk9sIamr7Yy/MMAdoo6t8TiLmkJ/PH3cnw97BfPcQUXif4fWKx2uc/f8ncrpS2RS3CKHNB3gruZgsD79Hdfl5E0T4pM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777150688; c=relaxed/simple; bh=+hSFQy10jXOwXKkPWQmI+ovca5nHeECfaZ4vk+Fo/YE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=YsK3/XbS+GKlWPSMjOp8XBSdgAOEerg4bZYzUVBW6cRHgtR42FqnbucgLxMFuUPZHo6Zi65UHM167SZMpMckKSL79DZPIo8NL7DgUHTWkmJBnYDz1nyASQEQip01WgyROwUCAKqcSp1w8DfkTgaoyiOMNKaIsPFAgdnZV3YhzfY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BcbK+xze; 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="BcbK+xze" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58321C2BCB0; Sat, 25 Apr 2026 20:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777150687; bh=+hSFQy10jXOwXKkPWQmI+ovca5nHeECfaZ4vk+Fo/YE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BcbK+xzeaaHw9zafOoOvGc7MHhe83Ktwvpsj77yR27U01k3Fog5Cu92T7e+Zgy+Rb DRkuvkSHMQbRZcRWTU64fej+2Cb61+rhjAC0pISZtsud0iql0tLkPeS55ZE426MtTI 53ULH9sFlXlUDcrLs6tMtBHqF0njXcP8xDORQFP4bG2rJJuYhkFtd0lcWYJaQU5Fs3 1/6v994uGrQ3Kfr3kUck4nTDKOhDnCmR1KUnzr/WltYvDPMqOs4LPfEoK/Ux2Fcc2r P46q/+Lik147WDM3VgtT/3jucTBQ7Sh/XjaTLMe+AhtMeVVWl0z4BAyqmSn/MkGGry Vb1FP+3dHuFSQ== From: "Barry Song (Xiaomi)" To: ryncsn@gmail.com Cc: akpm@linux-foundation.org, axelrasmussen@google.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, chenridong@huaweicloud.com, chrisl@kernel.org, david@kernel.org, hannes@cmpxchg.org, kaleshsingh@google.com, laoar.shao@gmail.com, lenohou@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, stevensd@google.com, surenb@google.com, vernon2gm@gmail.com, wangzicheng@honor.com, weixugc@google.com, yuanchu@google.com, yuzhao@google.com, zhengqi.arch@bytedance.com Subject: Re: [PATCH v6 00/14] mm/mglru: improve reclaim loop and dirty folio handling Date: Sun, 26 Apr 2026 04:57:59 +0800 Message-Id: <20260425205759.1701-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: References: 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: 8bit On Sat, Apr 25, 2026 at 9:30 PM Kairui Song wrote: [...] > > I just ran a matrix of for kernels (mainline, mm-new HEAD, before this > series, after this series) X 3 different memcg configs (-j96 3G, -j48 > 2G, -j24 1G), and none of these showed any regression but all > improvement. That's really odd. > > One possibility is that I removed the: > > if (evictable_min_seq(lrugen->min_seq, swappiness) + MIN_NR_GENS > > lrugen->max_seq) >     scanned = 0; > > Which will make the reclaim loop go further and trigger aging. > Previously if reclaim drained the LRU's cold gens, it may go reclaim > slab instead. So idle inodes will be dropped with the mapping and > reclaim more file, and we won't see any refault data from that since > the mapping itself is gone. Sys will be lower too, as IO isn't counted > as sys. Checking your data, despite sys is higher, real is acutually > lower, which matches my guess. > > Will the following patch help? I'm not sure if this is the problem, > but this added back that early abort, personally I don't think this > really makes much sense as it's more like a workaround for other > issues, but if that helps we might better keep it. Hi Kairui, after five hours of sleep I’m feeling much more refreshed and should have identified the issue. I think the problem will be clear once you look at the patch below. Feel free to include it in the new version if you find it helpful. >From e3a0b50dc53a3a5f2ef1adfb73111336e3c2d08b Mon Sep 17 00:00:00 2001 From: "Barry Song (Xiaomi)" Date: Sun, 26 Apr 2026 08:34:21 +1200 Subject: [PATCH] mm/mglru: Avoid falling back to another type when scan_folios() leaves no remaining pages While remaining reaches 0 in scan_folios(), we quickly fall back to the other type in isolate_folios(). This is incorrect, as the current type may still have sufficient folios. Falling back can undermine the positive_ctrl_err() result from get_type_to_scan(), which is derived from swappiness. A simple fix is to continue scanning this type for another round. Signed-off-by: Barry Song (Xiaomi) --- mm/vmscan.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index ef45f3a4aa38..169fbbe17c7b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4788,8 +4788,13 @@ static int isolate_folios(unsigned long nr_to_scan, struct lruvec *lruvec, *isolate_scanned = scanned; break; } - - type = !type; + /* + * If scanned > 0 and isolated == 0, avoid falling back to the + * other type, as this type remains sufficient. Falling back + * too readily can disrupt the positive_ctrl_err() bias. + */ + if (!scanned) + type = !type; } return total_scanned; -- 2.34.1 Thanks Barry