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 6AD08366DC1
	for <linux-kernel@vger.kernel.org>; Fri, 10 Jul 2026 03:22:48 +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=1783653770; cv=none; b=S7ROUximnYv8epy5z0tEhs6jTpcvzy5U2IZbinWEBHIiVULXcXfo0eSROQbPmEk1ZRuRRDXLOm1L4U1Q/9Ml//vHmlTI6peBW0dXnq6vYTklazkooXgVayGQVX7vCykWh+VlDI8ZDZuqEe5o0sma7eXGk6iiSU7dpol9CLOGfH8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783653770; c=relaxed/simple;
	bh=QGapEr1gOTKEnZnqIOw4W0GI7kHVRZ9WhX8Qzamaj2o=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=jA9V6SIFNlabYF/buisB/F2tFx7oUfoK3Qcj+DH+4Apg0Wl2BMWogGT1hwgoTiU7gHmhP59/2u+UrjZA09DM5YL2BC5bnAisRStscqRwTEAGX3TCwEIFD/M7w/Nhv5R8LmWnjd08A0U27UQ8w8cBcIXvH8Yn1W8uH81m/OQncP8=
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=WN5SsAby; 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="WN5SsAby"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1915B1F000E9;
	Fri, 10 Jul 2026 03:22:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1783653768;
	bh=ZFQO9/52qB1fORdUBg+bh7H1Rn2Vz3vYSgSrxS39etU=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=WN5SsAbyLtwDIDnw94+8JMcpio5fmYtyV1rsC+LIw3GGmEJx9oUyXOeQFts5+soJF
	 JkSbPNDvFV05oYsBb9hX3kyDqUX4GzaMjz2bs1eOWb38wRxzaPiqjM6yuscXdEdi/c
	 7rpKGXGqprSDtlQ2vPE1Fx5XmHMn6qwEOdTy4ErI=
Date: Thu, 9 Jul 2026 20:22:47 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Altan Hacigumus <ahacigu.linux@gmail.com>
Cc: David Hildenbrand <david@kernel.org>, Johannes Weiner
 <hannes@cmpxchg.org>, Kairui Song <kasong@tencent.com>, Qi Zheng
 <qi.zheng@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>, Barry Song
 <baohua@kernel.org>, Axel Rasmussen <axelrasmussen@google.com>, Yuanchu Xie
 <yuanchu@google.com>, Wei Xu <weixugc@google.com>, Lorenzo Stoakes
 <ljs@kernel.org>, "Liam R . Howlett" <liam@infradead.org>, Vlastimil Babka
 <vbabka@kernel.org>, Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan
 <surenb@google.com>, Michal Hocko <mhocko@suse.com>, Jiayuan Chen
 <jiayuan.chen@shopee.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmscan: clear hopeless kswapd when global direct
 reclaim makes progress
Message-Id: <20260709202247.8cf6d7ab840f3a45c7eac409@linux-foundation.org>
In-Reply-To: <20260710024429.70923-1-ahacigu.linux@gmail.com>
References: <20260710024429.70923-1-ahacigu.linux@gmail.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: <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-Transfer-Encoding: 7bit

On Thu,  9 Jul 2026 19:44:29 -0700 Altan Hacigumus <ahacigu.linux@gmail.com> wrote:

> Direct reclaim clears the hopeless kswapd state only once the node
> becomes balanced. This avoids cgroup memory.high reclaim repeatedly
> reviving a kswapd that cannot balance the node.
> 
> However, it also prevents global direct reclaim from reviving kswapd.
> Under sustained memory pressure, global direct reclaim may continue
> making progress without the node ever reaching the high watermark,
> leaving reclaim to allocating tasks.
> 
> Unlike memcg reclaim, global direct reclaim follows the same node-wide
> reclaim path as kswapd. Clear the hopeless state when global direct
> reclaim makes progress, while continuing to require a balanced node for
> memcg reclaim. kswapd_try_clear_hopeless() becomes static since struct
> scan_control is private to vmscan.c.
> 
> On a workload with most memory mlocked and the remainder under sustained
> churn, with swap enabled, comparing the same 60s window:
>                               base       patched
>   allocstall (all zones)    413441          6532
>   pgsteal_direct          15889552        255619
>   pgsteal_kswapd                 0      26079382
>   PSI memory full avg60     13.10%         9.37%
> 
> Direct reclaim was already reclaiming many pages in the baseline;
> this change lets kswapd resume doing that work asynchronously.

Does this change have any user-visible effect?  If so, please describe
in elaborate detail.

If not then that's OK - we make such changes all the time, but they're
less fun.