From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147])
	(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 0614A1A2C29
	for <linux-kernel@vger.kernel.org>; Thu, 19 Dec 2024 17:53:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1734630787; cv=none; b=bYVSBRz4LKgnAAoOB9zuUmd6z6fca20aIT9eJjyMVgkzIb3xgfd7Zesx10HC5OL0BjM1+JzJZM9WDisORsDf8prXpWZsO3V+btCB/GdGAgzcaUIhDhA8o2j44g8NPB3B7eBX8WR8i0/ZB+F+9B0fdUNWvTQGtpSkhvRpgsB13nY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1734630787; c=relaxed/simple;
	bh=CkKpQe6atsYpnKW/zC7uyX6XyA0bsM+FDucLe9MrO+8=;
	h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:
	 Content-Type:MIME-Version; b=OvT3Vh/Ydri3+BUGvZHbh9/rGWZk4l3cz6tgF2xugUV24R4Z5DxcawABrmRrNCkSYKEHvf774M2ScOyn+7uyoxzNnwnaM3sKG8WasdkckAJd62SzCwilOo+FvJuKvOq0IXLTByetpHd1j15l+mBlpqF1onGqHpmXxiyu9wMelTk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shelob.surriel.com
Received: from fangorn.home.surriel.com ([10.0.13.7])
	by shelob.surriel.com with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.97.1)
	(envelope-from <riel@shelob.surriel.com>)
	id 1tOKeu-000000008Pp-2Nv4;
	Thu, 19 Dec 2024 12:50:00 -0500
Message-ID: <ca363982c86fa57fe35b4723930a5d1f43e4210a.camel@surriel.com>
Subject: Re: [PATCH] mm: add maybe_lru_add_drain() that only drains when
 threshold is exceeded
From: Rik van Riel <riel@surriel.com>
To: David Hildenbrand <david@redhat.com>, Andrew Morton
	 <akpm@linux-foundation.org>
Cc: Chris Li <chrisl@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>, 
 "Matthew Wilcox (Oracle)"
	 <willy@infradead.org>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
	kernel-team@meta.com
Date: Thu, 19 Dec 2024 12:50:00 -0500
In-Reply-To: <de8c3dc8-7d36-419b-84f5-f886c6b724e6@redhat.com>
References: <20241218115604.7e56bedb@fangorn>
	 <189f4767-e7c2-4522-b943-b644126bf897@redhat.com>
	 <58d69446edb0e2b3b4edec442043cd0a9748f15f.camel@surriel.com>
	 <de8c3dc8-7d36-419b-84f5-f886c6b724e6@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) 
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
Sender: riel@surriel.com

On Thu, 2024-12-19 at 18:23 +0100, David Hildenbrand wrote:
> On 19.12.24 15:11, Rik van Riel wrote:
> >=20
> > I think we need to free those pending pages at
> > some point. They can't accumulate there forever.
> > However, I am not sure where those points should
> > be.
>=20
> The number of entries are limited,=C2=A0

...
> folio_batch_add() drains if folio_batch_space() returns 0 (no slots
> left).
>=20
> Apparently we have PAGEVEC_SIZE slots, which is 31 ... 31 * PAGE_SIZE
> stranded there.

Sure enough! That was the piece I was missing last night.

I guess we can get away with just draining these in the
reclaim and compaction paths, and not touch them the
rest of the time?

That could be a nice improvement in some situations.

--=20
All Rights Reversed.