From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 ABFFE3D9027 for ; Fri, 31 Jul 2026 08:39:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785487146; cv=none; b=hKO8hZzVbPZxqaakTrOnsDsi9yMu4LJt8J8n3iITmESyE0WQUGzM4wLHSNDrQ7+oWF30MOC7FETNKNgTz/cNMfXi1BrxAq/GUml6AXEejgDTQMpdDosF99wBRVn+OJH4SHU3hfuob0C8dMjqhMFf+v3FviLJCfpZSv+hMF0zjRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785487146; c=relaxed/simple; bh=gn0RARJRHyZuicJRTWIyBy/C/GTI+d5HNDMDlQw2Mbs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=BIvo98nj1/C98ZbPUaG+EC3k/q7X1jmlPPUn2KEHsZmS1NKV1ZD/FZVuFYQnI+rVRQnzu1SSkqFWCsHbLLUKxMGM3YVlZQUitIyzDhTHZ0bu/DTlGlBNS6DzOmRZrlePSh1IWQdrymxddKzUsuAb4JMqra3ppBb5CvuKFKkfrMg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AGKCawgR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AGKCawgR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3A621F00A3A; Fri, 31 Jul 2026 08:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785487145; bh=l1RvYFIQMTPrfL3d/VmiupnZ2Z7loXdewoH+NnJ+qiA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=AGKCawgRDVa9JVQhwQohtBa09MGFFkDREph4vYnF3B+JfGvStvZ0PIkk+2L+zYZI+ L9ZBTUCEKx9UEHkhSZrBXrg1Db0FY90P/1ohEhd/s50Q78YGgNQorq6K8oNKHZtPUI E39RZeQAsP7nJ2WzIE63IzQDh6x/us8qAqKrraimS3yw84mTnyUR8sbAmhlx9XP92C WHLpAAHxPod6IEYSXCYRSQu5WdcyqMGiEcwVtAzEtwLwZayVlaogdnYfuRkDdhyd/c Lz38uMsMMSUUKZt4BesUUrdHvksZEKHjzo5pTCdjwmoSVKBvT0QsNHqpcVFI74pyRD pkm+VKIALvOZw== From: "Barry Song (Xiaomi)" To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: axelrasmussen@google.com, david@kernel.org, hannes@cmpxchg.org, kasong@tencent.com, linux-kernel@vger.kernel.org, ljs@kernel.org, lyugaofei@xiaomi.com, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, stevensd@chromium.org, weixugc@google.com, yuanchu@google.com, chenridong@xiaomi.com, zhangbo56@xiaomi.com, wangzicheng@honor.com, lianux.mm@gmail.com, "Barry Song (Xiaomi)" Subject: [RFC PATCH v3 1/6] mm: mglru: prevent min_seq[type] from pointing to an empty generation Date: Fri, 31 Jul 2026 16:38:38 +0800 Message-Id: <20260731083843.37811-2-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260731083843.37811-1-baohua@kernel.org> References: <20260731083843.37811-1-baohua@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In try_to_inc_min_seq(), min_seq[LRU_GEN_ANON] and min_seq[LRU_GEN_FILE] can be adjusted to point to empty generations to keep their gap within one. As a result, scan_folios() may repeatedly scan empty generations because it assumes the min_seq generation still contains folios. Likewise, should_run_aging() has no way to tell that the min_seq generation has already been drained. This is quite confusing. I observed scan_folios() returning 0 even though the following check in scan_folios() doesn't take effect: if (get_nr_gens(lruvec, type) == MIN_NR_GENS) return 0; There is no need to adjust min_seq[], since the reclaim logic already triggers aging when the number of generations reaches MIN_NR_GENS, and reclaim never reduces it below MIN_NR_GENS. Signed-off-by: Barry Song (Xiaomi) --- include/linux/mmzone.h | 6 ++---- mm/vmscan.c | 10 ---------- 2 files changed, 2 insertions(+), 14 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index a26c8b855222..233d2006a541 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -552,10 +552,8 @@ enum { * The youngest generation number is stored in max_seq for both anon and file * types as they are aged on an equal footing. The oldest generation numbers are * stored in min_seq[] separately for anon and file types so that they can be - * incremented independently. Ideally min_seq[] are kept in sync when both anon - * and file types are evictable. However, to adapt to situations like extreme - * swappiness, they are allowed to be out of sync by at most - * MAX_NR_GENS-MIN_NR_GENS-1. + * incremented independently. For both file and anonymous memory, the minimum + * generation must be at least MIN_NR_GENS. * * The number of pages in each generation is eventually consistent and therefore * can be transiently negative when reset_batch_size() is pending. diff --git a/mm/vmscan.c b/mm/vmscan.c index 566c4e837c7d..ce027c271e9b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3972,16 +3972,6 @@ static void try_to_inc_min_seq(struct lruvec *lruvec, int swappiness) if (!seq_inc_flag) return; - /* see the comment on lru_gen_folio */ - if (swappiness && swappiness <= MAX_SWAPPINESS) { - unsigned long seq = lrugen->max_seq - MIN_NR_GENS; - - if (min_seq[LRU_GEN_ANON] > seq && min_seq[LRU_GEN_FILE] < seq) - min_seq[LRU_GEN_ANON] = seq; - else if (min_seq[LRU_GEN_FILE] > seq && min_seq[LRU_GEN_ANON] < seq) - min_seq[LRU_GEN_FILE] = seq; - } - for_each_evictable_type(type, swappiness) { if (min_seq[type] <= lrugen->min_seq[type]) continue; -- 2.34.1