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 9CA652E7179 for ; Wed, 12 Aug 2026 01:42:42 +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=1786498963; cv=none; b=f6YZyOxU0E+vSKauvipaugOmJpx6ZKoaamMR8jgyFhcJWFpQiYB62ds7t6+1yLZ4UIJragNjJcLip+4l4fooZM0P2UU3t7hJ51mcJv3U2y/7asmV9c3Ipw+96ra/jSR47Y3R+tF70CsbO4PFKn9Txqz6QtR5Wj2bsmaMdTyW6rs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786498963; c=relaxed/simple; bh=HZlIWerOCWXIHmZlpVfwQUWhslzoEOhYNlegK8R4yzU=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=nNaJXUuVBVK71udKeiskj3O6wCkQBvaio/qNB2JSS5vsB1ckSVc2fR4+klqMR6fK+Rr+pRrpJMnxuYNI7ojOH8gpP7bmy5jZPsIq90SmNB0GTRrzanuhjjjWQXBG0cI2NobCUDNvDR9GechR0w9hF4ZNU6qggC2Cbbo7haPYkoY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=xB6wSOwT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="xB6wSOwT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C40E21F000E9; Wed, 12 Aug 2026 01:42:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786498962; bh=0ZU8DXDgfl8l62Gk1D2XRPtVmat7xNwylWclqwtu80A=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=xB6wSOwTrIILgb6EqeeBEk9OxI/Pqk3sH0e3eYLsqkOzDo8/Es1m3vY5hhNHWrX8k t0m9poWiXWnm5DJ9uSqedQ7xBjX0otEjvkFSzXG5G/a+krdwjzQHBCJ8B/8xyThZGA eKssDGxq4ZhqHzs/6tGmm/LDE56wKo0oUVbEgwno= Date: Tue, 11 Aug 2026 18:42:41 -0700 From: Andrew Morton To: Wupeng Ma Cc: , , , , , , , , , , , Subject: Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning Message-Id: <20260811184241.e423b81c8a50d5f212af1c3b@linux-foundation.org> In-Reply-To: <20260811070849.1332165-1-mawupeng1@huawei.com> References: <20260811070849.1332165-1-mawupeng1@huawei.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 11 Aug 2026 15:08:47 +0800 Wupeng Ma wrote: > shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but > isolate_lru_folios() may scan far more than that per call on a single > LRU. The excess is never charged back, so shrink_lruvec() keeps > rescanning the same folios round after round. When reclaim targets a > lower zone, the same scanner also keeps walking zone-ineligible folios > that can never satisfy the allocation, inflating nr_reclaimed into a > false progress that delays the OOM. > > This series fixes both: > > [1/2] Charge the isolate overshoot against the scan quota so the > next round skips already-scanned folios. > [2/2] Stop scanning once too many zone-ineligible folios have been > skipped, instead of force-isolating them. This all sounds fairly bad. Is there some report? Real-world test results? Laboratory test results? Something to help us understand the impact of the issues and the situations in which they occur. Thanks.