From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180])
	(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 3171A1C84D7
	for <linux-kernel@vger.kernel.org>; Thu, 16 Apr 2026 21:49:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.180
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776376187; cv=none; b=U0EraC6oLZfa/3yF+L7O7noSmckTN1LtMHZMtwK8eoU8ZRvYHNQQaSdBOTYOZNAg8KihduuO5/G/KEPRBHR5C/hlYmzFGtzNRaIAH4+sgmt7lS+2gCe/1ZZG4Zp1xQCgKNRUgtz7LdrfsIDnnm+wWc/+x5P//1dkGu6JN9RZ4NQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776376187; c=relaxed/simple;
	bh=gJA63cCPR5t2pHUoi3oaav4y/kfmT1xNf3ULsyp9xs4=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=lBrXv3RCOA+sMmb/bde3b8RxS5QOwhWuVDM50tf9W0Kp/g0Zr1rCBtivHXMXraWu6qnuMlvLeXi5blUR8jBVyrdhDlmStopz4MNSlGyhZm+yaMmqERmzKpYKtaEJzR0gvZNCC59I5fxkTbSf3EAME3T19IdX0dWSfUZa8GMH7Us=
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=Z7fUs5gH; arc=none smtp.client-ip=95.215.58.180
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="Z7fUs5gH"
Date: Thu, 16 Apr 2026 14:49:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1776376182;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=yvn2jbgbxVPa/dgGDSzpzj/SD9CZWwQkugRH34yO08g=;
	b=Z7fUs5gH89FOSfMI9saN+Mby3wvAW71DOFfNOEucQSEDOB3KjaGIRufT2wxCv5E7n5wy2R
	Ro99vrtZYZ6Ttjw2NV0gdwDViWdAW+Tsqxl9bMC6kglcW/KH/qcWdTbkcMdsOptx9uqltL
	Rek9Tdd4RFbbuxKoXxSK12K0qPK+jsA=
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Shakeel Butt <shakeel.butt@linux.dev>
To: Matt Fleming <matt@readmodwrite.com>
Cc: Pedro Falcato <pfalcato@suse.de>, 
	Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, 
	Jens Axboe <axboe@kernel.dk>, Sergey Senozhatsky <senozhatsky@chromium.org>, 
	Roman Gushchin <roman.gushchin@linux.dev>, Minchan Kim <minchan@kernel.org>, kernel-team@cloudflare.com, 
	Matt Fleming <mfleming@cloudflare.com>, Johannes Weiner <hannes@cmpxchg.org>, 
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, 
	Kemeng Shi <shikemeng@huaweicloud.com>, Nhat Pham <nphamcs@gmail.com>, Baoquan He <bhe@redhat.com>, 
	Barry Song <baohua@kernel.org>, Vlastimil Babka <vbabka@kernel.org>, 
	Suren Baghdasaryan <surenb@google.com>, Michal Hocko <mhocko@suse.com>, 
	Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>, 
	Axel Rasmussen <axelrasmussen@google.com>, Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>, 
	David Hildenbrand <david@kernel.org>, Qi Zheng <zhengqi.arch@bytedance.com>, 
	Lorenzo Stoakes <ljs@kernel.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct
 reclaim
Message-ID: <aeFYrV78Q19c-RnB@linux.dev>
References: <20260410101550.2930139-1-matt@readmodwrite.com>
 <v3j7f476gbj7b5rxigpcorxhaimg5dyhgtovsl5quo7gc33swc@7i4ypekahw5h>
 <aeDuVmN8Q6cpNTuT@matt-Precision-5490>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aeDuVmN8Q6cpNTuT@matt-Precision-5490>
X-Migadu-Flow: FLOW_OUT

On Thu, Apr 16, 2026 at 03:51:04PM +0100, Matt Fleming wrote:
> On Wed, Apr 15, 2026 at 03:57:25PM +0100, Pedro Falcato wrote:
[...]
> 
> > My theory (from merely reading the patch, maybe I missed something) is that
> > a pathological case for this is a lot of folios added to the LRU in a row,
> > that are set referenced (or dirty). Say SWAP_CLUSTER_MAX * MAX_RECLAIM_RETRIES
> > - it will simply OOM too early.
>  
> OK yeah I think I see the problem now: this heuristic applies the
> threshold against all reclaimable pages but that falls apart when doing
> SWAP_CLUSTER_MAX chunks of reclaim.

I am not sure I understand the pathological case. Yes SWAP_CLUSTER_MAX is
requested amount of pages to reclaim but the kernel can potentially scan full
memory twice to reclaim that much amount. Though those reclaimed pages can get
stolen but that can still happen today before this patch.