linux-kernel - Re: [PATCH v1] mm/vmscan: mitigate spurious kswapd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aV0HI2-iRXuQ4MGv@tiehlicka>
Date: Tue, 6 Jan 2026 13:59:15 +0100
From: Michal Hocko <mhocko@...e.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, linux-mm@...ck.org,
	Jiayuan Chen <jiayuan.chen@...pee.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	David Hildenbrand <david@...nel.org>,
	Qi Zheng <zhengqi.arch@...edance.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm/vmscan: mitigate spurious kswapd_failures reset
 from direct reclaim

On Tue 06-01-26 11:19:21, Jiayuan Chen wrote:
> January 6, 2026 at 17:49, "Michal Hocko" <mhocko@...e.com mailto:mhocko@...e.com?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > wrote:
> 
> 
> > 
> > On Tue 06-01-26 05:25:42, Jiayuan Chen wrote:
> > 
> > > 
> > > That said, I believe this patch is still a valid fix on its own - resetting kswapd_failures
> > >  when the node is not actually balanced doesn't seem like correct behavior regardless of the
> > >  broader context.
> > > 
> > Originally I was more inclined to opt out memcg reclaim from reseting
> > kswapd retry counter but the more I am thiking about that the more your
> > patch makes sense to me. 
> > 
> > The reason being that it handles both memcg and global direct reclaims
> > in the same way which makes the logic easier to follow. Afterall the
> > primary purpose is to resurrect kswapd after we can see there is a
> > better chance to reclaim something for kswapd. Until that moment direct
> > reclaim is the only reclaim mechanism.
> > 
> > Relying on pgdat_balanced might lead to re-enabling kswapd way much
> > later while memory reclaim would be still mostly direct reclaim bound -
> > thus increase allocation latencies.
> > If we wanted to do better we would need to evaluate recent
> > refaults/thrashing behavior but even then I am not sure we can make a
> > good cut off.
> > 
> > So in the end pgdat_balanced approach seems worth trying and see whether
> > this could cause any corner cases.
> 
> Thanks Michal.
> 
> Regarding the allocation latency concern - we are already
> in the direct reclaim slowpath, so a little extra overhead
> from the pgdat_balanced check should be negligible.

Yes, I do not think that pgdat_balanced call itself adds to the latency
in the reclaim (slow) path. Mine main concern regarding latencies is
about direct reclaim as a sole source of reclaim itself (as kswapd is
not active).
-- 
Michal Hocko
SUSE Labs