Re: [RFC PATCH 0/1] mm: Reduce direct reclaim stalls with RAM-backed swap

[Shakeel Butt <shakeel.butt@linux.dev>]

On Tue, Mar 03, 2026 at 07:37:54PM +0000, Matt Fleming wrote:
> On Tue, Mar 03, 2026 at 06:59:04AM -0800, Shakeel Butt wrote:
> > Hi Matt,
> > 
> > Thanks for the report and one request I have is to avoid cover letter for a
> > single patch to avoid partitioning the discussion.
>  
> Noted.
> 
> > Have you tried zswap and if you see similar issues with zswap?
>  
> Yes, we've started experimenting with zswap but that's still in
> progress.
> 
> > Over the time we (kernel MM community) have implicitly decided to keep the
> > kernel oom-killer very conservative as adding more heuristics in the reclaim/oom
> > path makes the kernel more unreliable and punt the aggressiveness of oom-killing
> > to the userspace as a policy. All major Linux deployments have started using
> > userspace oom-killers like systemd-oomd, Android's LMKD, fb-oomd or some
> > internal alternatives. That provides more flexibility to define the
> > aggressiveness of oom-killing based on your business needs.
> > 
> > Though userspace oom-killers are prone to reliability issues (oom-killer getting
> > stuck in reclaim or not getting enough CPU), so we (Roman) are working on adding
> > support for BPF based oom-killer where wen think we can do oom policies more
> > reliably.
> > 
> > Anyways, I am wondering if you have tried systemd-oomd or some userspace
> > alternative. If you are interested in BPF oom-killer, we can help with that as
> > well.
> 
> oomd is also being discussed but so far we haven't experimented with it
> yet.
> 
> What's the status of BPF oom-killer: is this the latest?
> 
>   https://lore.kernel.org/all/20260127024421.494929-1-roman.gushchin@linux.dev/

Yes this is the latest and I think Roman is planning to send the next version
soon.