linux-kernel - Re: [PATCH v2] mm/vmscan: skip increasing 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: <7rx23a4moclrdb6csumf2g3kfp7rgy7przq6lsknwumeb35x2c@jhrmjdcfhzcf>
Date: Thu, 13 Nov 2025 15:41:00 -0800
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, 
	Johannes Weiner <hannes@...xchg.org>, David Hildenbrand <david@...hat.com>, 
	Michal Hocko <mhocko@...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 v2] mm/vmscan: skip increasing kswapd_failures when
 reclaim was boosted

On Wed, Nov 12, 2025 at 02:21:37AM +0000, Jiayuan Chen wrote:
> 2025/11/8 09:11, "Shakeel Butt" <shakeel.butt@...ux.dev mailto:shakeel.butt@...ux.dev?to=%22Shakeel%20Butt%22%20%3Cshakeel.butt%40linux.dev%3E > wrote:
[...]
> > If this issue (high protection causing kswap
> > failures) happen on non-boosted case, I am not sure what should be right
> > behavior i.e. allocators doing direct reclaim potentially below low
> > protection or allowing kswapd to reclaim below low. For min, it is very
> > clear that direct reclaimer has to reclaim as they may have to trigger
> > oom-kill. For low protection, I am not sure.
> >
> 
> We have also encountered this issue in non-boosted scenarios. For instance, when
> we disabled swap (meaning only file pages are reclaimed, not anonymous pages), it
> indeed occurred even without memory.low configured, especially when anonymous pages
> constituted the majority.

Basically whenever the amount of reclaimable memory is low (i.e. in the
range where it is very hard to satisfy the watermarks), this issue can
happen. 'This' as in kswapd failures. This functionality was added to
detect such scenarios where kswapd hogs a CPU doing nothing. The
memory.low adds a twist that we can allow kswapd to go after but let's
punt on that for now and go after the clear and easy issue i.e. kswapd
failures due to boosted watermarks.