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 9F8283BF68E for ; Mon, 13 Apr 2026 15:38:27 +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=1776094707; cv=none; b=uPsy0u/1aQjo4lQWzH4IOPF4WxpbdzBd/yrF/xku4Dn9gbzTwc42wKWHvMns0uio6AUJA+qmNAz2k/V/zoLDERV75mCl1G744syatbyy4OHrAE8hfsleK+Iu/c+w5GSaOyrV6H/XXIKRQvgkFS0zeMivVqDhjgUwIcYs9UFAyv4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776094707; c=relaxed/simple; bh=mZpRvz7G8OpmAEE71Wnk9PIg6d1HTndlpxTz7DDiNKg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PfFaHQ+t4G9p+RDmuvX479GWmCxHfmMlWIKyl+n5o1dhOXKhkYnLDMfEtJuMRVTbCDZgKp1hEb+h+fWV65JoPSg8FGPkEtuvLZ1EPc6MFdGBhUZr//t4JBcdm8UhdQNoPRrnNTiWr/qWq1T+1d5gC+XKMFElNxFwRhJgDBrMyms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nLWZvOC7; 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="nLWZvOC7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54969C2BCAF; Mon, 13 Apr 2026 15:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776094707; bh=mZpRvz7G8OpmAEE71Wnk9PIg6d1HTndlpxTz7DDiNKg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nLWZvOC7HXFamfr3d32XycFsgIQfHX370qoWehj9VS13JL9VHdZVOjADoNWax3WK1 8VsI0/KOM8L0oM3UiwNBqCRARPFU4i9VHi7RFiws0cf2/eHoAZHrlB30lLlKgTqDXe ecQ+rhI/BhzMxosHSIIAPdlPQxwjbDd6rOYskb1CDATWCybduvc0o1cN0Yc9gqch2F +Mrsg+VOiflf9XEoulGInr5BLopDQhBGe4miCALqYeO25d2EFKUzvf4MDq1wfAUx4x 1x8ZqAERHk3ArhlRo516dYON3z2FAtsLIzVDngdbY6TN3eGcyQP2aQ3lg6PgOVjJSt K7VvpIw7EcGLg== Message-ID: <6ca33173-145b-43aa-8a8a-34985d375246@kernel.org> Date: Mon, 13 Apr 2026 17:38:19 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim Content-Language: en-US To: Matt Fleming , Andrew Morton Cc: Christoph Hellwig , Jens Axboe , Sergey Senozhatsky , Roman Gushchin , Minchan Kim , kernel-team@cloudflare.com, Matt Fleming , Johannes Weiner , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260410101550.2930139-1-matt@readmodwrite.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260410101550.2930139-1-matt@readmodwrite.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/10/26 12:15, Matt Fleming wrote: > From: Matt Fleming > > should_reclaim_retry() uses zone_reclaimable_pages() to estimate whether > retrying reclaim could eventually satisfy an allocation. It's possible > for reclaim to make minimal or no progress on an LRU type despite having > ample reclaimable pages, e.g. anonymous pages when the only swap is > RAM-backed (zram). This can cause the reclaim path to loop indefinitely. > > Track LRU reclaim progress (anon vs file) through a new struct > reclaim_progress passed out of try_to_free_pages(), and only count a > type's reclaimable pages if at least reclaim_progress_pct% was actually > reclaimed in the last cycle. > > The threshold is exposed as /proc/sys/vm/reclaim_progress_pct (default > 1, range 0-100). Setting 0 disables the gate and restores the previous > behaviour. Environments with only RAM-backed swap (zram) and small > memory may need a higher value to prevent futile anon LRU churn from > keeping the allocator spinning. > > Suggested-by: Johannes Weiner > Signed-off-by: Matt Fleming Hi Matt, so have you tested it for your usecase with zram and have any observations how it helped, what values did you set etc? Vlastimil