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: <jbqwxqsqvjqo664s275hcub5wgnjencvqgisiniflylp2fpxz5@imttckfazi7u>
Date: Thu, 13 Nov 2025 11:28:58 -0800
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Michal Hocko <mhocko@...e.com>
Cc: Jiayuan Chen <jiayuan.chen@...ux.dev>, linux-mm@...ck.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, 
	David Hildenbrand <david@...hat.com>, 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 Thu, Nov 13, 2025 at 11:02:41AM +0100, Michal Hocko wrote:
> > 
> > In general I think not incrementing the failure for boosted kswapd
> > iteration is right. 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.
> 
> Our current documention gives us some room for interpretation. I am
> wondering whether we need to change the existing implemnetation though.
> If kswapd is not able to make progress then we surely have direct
> reclaim happening. So I would only change this if we had examples of
> properly/sensibly configured systems where kswapd low limit breach could
> help to reuduce stalls (improve performance) while the end result from
> the amount of reclaimed memory would be same/very similar.

Yes, I think any change here will need much more brainstorming and
experimentation. There are definitely corner cases which the right
solution might not be in kernel. One such case I was thinking about is
unbalanced (memory) numa node where I don't think kswapd of that node
should do anything because of the disconnect between numa memory usage
and memcg limits. On such cases either numa balancing or
promotion/demotion systems under discussion would be more appropriate.
Anyways this is orthogonal.

> 
> This specific report is an example where boosting was not low limit
> aware and I agree that not accounting kswapd_failures for boosted runs
> is reasonable thing to do. I am not yet sure this is a complete fix but
> it is certainly a good direction.

Yes, I think we should move forward with this and keep an eye if this
situation occurs in non-boosted environment.