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 56061381EA1 for ; Sun, 26 Jul 2026 12:21:35 +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=1785068496; cv=none; b=DDtFtaWmXnR13jZODk0WjfPVbmAqj2Tj3X7n+sGa4XcAz0V+JFhhFblo36jAwJA9mYupUCsmWD3zKejG1ocXG6XPg+tzJ3UT0YBiNZWyiM/D5L73l5qbhjomX8cf5ucxJ4sdKBUTRodwKwkVJdRcVll8QVQa5Z5Jn1VL4la8wQM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785068496; c=relaxed/simple; bh=upBERFv3S0t36KmomHV9Ry6AaOKDjDuuMJYMgbOZnBw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=TURpJnhgWvC3S6qlyAg6QhYcWwTrorZbc0l7aotVBBbkxwEaazU7ZlHXR6b08rSjsKC308ZAQ+C3ktZ+wouprs0vLl8PzbWM/bT2D/IW+oeKfnJGYiPfUE3gOjT2IevTE5m1qfY4Ubycjiuex+ESvxUKzEhm6RvtqOS5kmC4dxk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lw4Gd1Iy; 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="Lw4Gd1Iy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40F5E1F00A3A; Sun, 26 Jul 2026 12:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785068495; bh=cMhtlkfEDVE3WxvRE/7goFu25836RScGrqUUGkruj54=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Lw4Gd1Iy1sT7rxfxj3C2JKV/UjyvDgWvUdK9mj7wUSfhjV/Txdqrw9DsgPC5/8xuG 4m8lN/OQYY+WLY6OiwwR0nr3662ZQa11d3WeGdqxwb3mx3dIi+cX1w5SZlrxrv5rfY NxIhbGqQoeIV17vcGY/APzrVu+gZ16ZyB5BSK6ZPA6dTmymIEyCEl9EEhiwoPlBjR5 W5aBuyob3tyGafxqDDqK7JeHmW90h8XLue6dOzkJHVnKAjW5Pr1QAtqs2ZyYcFwMRr Cj3mmmGk9ew3nHjs5cva4KhMHlPOJUVGG02NWlvs0TvD3TcKC+5z3wO9BewpxC8Xwd T8JZWuwcwlvnQ== 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 1/5] mm: mglru: avoid scanning empty generations in scan_folios() Date: Sun, 26 Jul 2026 20:21:19 +0800 Message-Id: <20260726122123.7614-2-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 Commit 16b475d2ac3c ("mm/mglru: avoid reclaim type fall back when isolation makes no progress") only falls back to the other type when scanned == 0. However, I have frequently observed cases where scanned > 0, but the older reclaimable generation becomes empty after the first scan_folios(). As a result, the second scan_folios() for the same type performs a redundant scan over an empty generation. We can avoid this by checking whether the reclaimable generation has become empty when scanned < nr_to_scan and we still have fewer than MIN_LRU_BATCH isolated folios after scan_folios(). Signed-off-by: Barry Song (Xiaomi) --- mm/vmscan.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 566c4e837c7d..babbce4bbfe8 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4852,11 +4852,14 @@ static int isolate_folios(unsigned long nr_to_scan, struct lruvec *lruvec, break; } /* - * 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 >= nr_to_scan or isolated >= MIN_LRU_BATCH, + * avoid falling back to the other type. The preferred + * type is still reclaimable; otherwise, it would have + * already run out of reclaimable generations. Falling + * back too readily can disrupt the positive_ctrl_err() + * bias. */ - if (!scanned) + if (scanned < nr_to_scan && *isolated < MIN_LRU_BATCH) type = !type; } -- 2.39.3 (Apple Git-146)