From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (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 E97EA3203B6 for ; Thu, 16 Apr 2026 21:58:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776376725; cv=none; b=RkGHMhCp/62hfe2GLyE8aH94Is5AlcFb8Yl0YmVKR57pBteED/Q0l68IQC3nzsRHgtDnMW7OsBjySeiIFD8cvatbnDxB/iksV827JMQfzueukC+J+ijVCP31npm7y4abNrMNTfgUoLxT4cuwGjAkd8dQ+TuejPo9UYS3AooeGXs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776376725; c=relaxed/simple; bh=jSTNhjSP6uVTXAB18vay+h79DX7ROA0DFMtYhW8N9rM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DKL2fPyNdmzMguqahowLtMHNtr00DUX8R70JHI4y84v0ODUVHrk6upp3B3WhHxo8Jba/BmTQceRIDTTr7mvH2u9e6UtuMlu68d3i+6EhMbq+/CHfuwqO8Z68JikwXJhvEBfoLM4YKao4Ime/yGbiQqjZ3MhrSjuPsipdE17UHps= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=MOHknOXa; arc=none smtp.client-ip=95.215.58.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="MOHknOXa" Date: Thu, 16 Apr 2026 14:58:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776376721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nfB7yq7FlvDsj7E7RUcfKGzlsn3Xjn7/O/KFA2Tgztw=; b=MOHknOXa1MVcRU46Icm27zBTaxGkHx2XgdKJ200CHpwza9iBh9YShQYCrjYlPykeix+6xC s9wuzFyfm5Vn6mK0DqJYEc550qXEZgd59qciSvM685E5DGtcOkjDusLRio9Pdq/kGP7cVO UVkWNz2IdfRjJQauhJirQFs9Ono8vDI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Barry Song Cc: Matt Fleming , Andrew Morton , 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 , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Qi Zheng , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim Message-ID: References: <20260410101550.2930139-1-matt@readmodwrite.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT On Thu, Apr 16, 2026 at 09:44:55AM +0800, Barry Song wrote: > On Fri, Apr 10, 2026 at 6:16 PM 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. > > I am still struggling to understand when zram-backed > reclamation cannot make progress. Is it because zram is > full, or because folio_alloc_swap() fails? > > Or does zs_malloc() fail, causing pageout() to fail? > Even incompressible pages are still written as > ZRAM_HUGE pages and reclaimed successfully. We should have counters for these, right? > > > > > 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. > > I would rather detect what causes the lack of progress > and implement a better fallback. This is a good question. I think we have appropriate counters in /proc/vmstat for cases where pages keep getting recycled in the LRUs instead of reclaim. Matt, do you see anything unexpected in /proc/vmstat?