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 A95A02D0C62 for ; Sun, 26 Jul 2026 12:21:41 +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=1785068502; cv=none; b=NgcJrP6HGl7FH4aYqTZTTC0oJxHt33bjSvHeztWBqd6CqZ3s/D/GYOABxc05e8cA/SbLDYho563bQQKXfG4AELrGsjiVhD0de3QYJgk+Xi+5xPuEMGxIW23IxpOnJTmooRElv7kbBiQODruUXSTnd4Fl71Ti3pb0q9n5SEsM1C0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785068502; c=relaxed/simple; bh=ivz2OZ3ZXJGQbnZtXCKM69WJSm6BpxeRLRKtSNN0gE0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=l8FrLM0GLe/xpXs3Gvye60j9KGZ9qNk983DXO1AiGDYFg1cMYEyV79EZfuS742IHsjOYHG7yOn4mhzBP2jXeEO3rKjiMfjWZ2ml3C/6YEUDULtYigLGZA9tJ9+tAcmQyp2vuqD/vq1dej1xir61EmSaLfSGeTokVpQb895iZ9KM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Gi3JlaCg; 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="Gi3JlaCg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B95F1F00A3E; Sun, 26 Jul 2026 12:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785068501; bh=LkwAEEFWY7JzMw6txcP0Z68llfDTMNlFyazJA9AKKho=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Gi3JlaCgRLPOXMx+AwXsw4LLuWg3X4Ew8OKpudKKwXilVxTjz9UtB0Q9gOGu5vOvx OKptOJJRSqKIzR+001p+ldbXjw7dwSGac4XPp3XaoLeQtdbGSO11jmrp1WGFJ4MS/A h4Dnfr2xVR3fUlEFi/9Th3/EBMbzqd24e/25HJHAdSuObYt5tMNX6eynLZlsgX3Rqp Rx4fd2CuNY7g3R0a056G7pvPDU29qBBJHbbhqaKiTdhFTkvLtCgapZfRIcUTMTCcim l2hGgHzYfZfquVTBBhovaWCDyddegRpoR1eU/2ZlfbXKZu7Y6PK8Gl3ndqdFsdQFpP F4n11GqsHUAXw== From: "Barry Song (Xiaomi)" To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: hannes@cmpxchg.org, david@kernel.org, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, ljs@kernel.org, kasong@tencent.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, linux-kernel@vger.kernel.org, lyugaofei@xiaomi.com, stevensd@chromium.org, "Barry Song (Xiaomi)" Subject: [RFC PATCH v2 3/5] mm: mglru: prevent min_seq[type] from pointing to an empty generation Date: Sun, 26 Jul 2026 20:21:21 +0800 Message-Id: <20260726122123.7614-4-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260726122123.7614-1-baohua@kernel.org> References: <20260726122123.7614-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 fixed up to point to empty generations in order to keep their gap within one. As a result, scan_folios() may repeatedly scan empty generations. This is confusing, as 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 4a387cc4145a..d6bd64b4dced 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.39.3 (Apple Git-146)