linux-kernel - Re: [PATCH v1] mm/vmscan: Add retry logic for cgroups with memory.low in 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: <46df65477e0580d350e6e14fea5e68aee6a2832b@linux.dev>
Date: Thu, 16 Oct 2025 15:10:31 +0000
From: "Jiayuan Chen" <jiayuan.chen@...ux.dev>
To: "Michal Hocko" <mhocko@...e.com>
Cc: linux-mm@...ck.org, "Andrew Morton" <akpm@...ux-foundation.org>, "Axel
 Rasmussen" <axelrasmussen@...gle.com>, "Yuanchu Xie"
 <yuanchu@...gle.com>, "Wei Xu" <weixugc@...gle.com>, "Johannes Weiner"
 <hannes@...xchg.org>, "David Hildenbrand" <david@...hat.com>, "Qi Zheng"
 <zhengqi.arch@...edance.com>, "Shakeel Butt" <shakeel.butt@...ux.dev>,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm/vmscan: Add retry logic for cgroups with
 memory.low in kswapd

October 16, 2025 at 22:49, "Michal Hocko" <mhocko@...e.com mailto:mhocko@...e.com?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > wrote:


> >  
> >  Thanks Michal, let me explain the issue I encountered:
> >  
> >  1. When kswapd is triggered and there's no reclaimable memory (sc.nr_reclaimed == 0),
> >  this causes kswapd_failures counter to continuously accumulate until it reaches
> >  MAX_RECLAIM_RETRIES. This makes the kswapd thread stop running until a direct memory
> >  reclaim is triggered.
> > 
> While the definition of low limit is rather vague:
>  Best-effort memory protection. If the memory usage of a
>  cgroup is within its effective low boundary, the cgroup's
>  memory won't be reclaimed unless there is no reclaimable
>  memory available in unprotected cgroups.
>  Above the effective low boundary (or
>  effective min boundary if it is higher), pages are reclaimed
>  proportionally to the overage, reducing reclaim pressure for
>  smaller overages.
> which doesn't explicitly rule out reclaim from the kswapd context but
> historically we relied on the direct reclaim to detect the "no
> reclaimable memory" situation as it is much easier to achieve in that
> context. Also you do not really explain why backing off kswapd when all
> the reclaimable memory is low limit protected is bad.

Thanks for providing this context.


> > 
> > 2. We observed a phenomenon where kswapd is triggered by watermark_boost rather
> >  than by actual memory watermarks being insufficient. For boost-triggered
> >  reclamation, the maximum priority can only be DEF_PRIORITY - 2, making memory
> >  reclamation more difficult compared to when priority is 1.
> > 
> Do I get it right that you would like to break low limits on
> watermark_boost reclaim? I am not sure I follow your priority argument.
> 
> -- 
> Michal Hocko
> SUSE Labs
>

The issue we encountered is that since the watermark_boost parameter is enabled by
default, it causes kswapd to be woken up even when memory watermarks are still relatively
high. Due to rapid consecutive wake-ups, kswapd_failures eventually reaches MAX_RECLAIM_RETRIES,
causing kswapd to stop running, which ultimately triggers direct memory reclaim.

I believe we should choose another approach that avoids breaking the memory.low semantics.
Specifically, in cases where kswapd is woken up due to watermark_boost, we should bypass the
logic that increments kswapd_failures.