Re: [DISCUSS] Proposal: move slab shrinking into a dedicated kernel thread to improve reclaim efficiency

[Christoph Hellwig <hch@infradead.org>]

[adding Dave who has spent a lot of time on shrinkers]

On Tue, Oct 21, 2025 at 10:52:41AM +0800, Yifan Ji wrote:
> Hi all,
> 
> We've been profiling memory reclaim performance on mobile systems and found
> that slab shrinking can dominate reclaim time, particularly when multiple
> shrinkers are active. In some cases, shrink_slab() introduces noticeable
> latency in both direct reclaim and kswapd contexts.
> 
> We are exploring an approach to move slab shrinking into a dedicated kernel
> thread, decoupling it from direct reclaim and kswapd. The goal is to perform
> slab reclaim asynchronously under controlled conditions such as idle periods
> or vmpressure triggers.

That would mirror what everyone in reclaim / writeback does and have the
same benefits and pitfalls like throttling.  I'd suggest you give it a
spin and report your findings.

> Motivation:
>  - Reduce latency in direct reclaim paths.
>  - Improve reclaim efficiency by separating page and slab reclaim.
>  - Provide more flexible scheduling for slab shrinking.
> 
> Proposed direction:
>  - Introduce a kernel thread that periodically or conditionally calls
> shrink_slab().
> 
> We'd appreciate feedback on:
>  - Whether this decoupling aligns with the design of the current reclaim model.
>  - Possible implications on fairness, concurrency, and memcg behavior.
> 
> Thanks for your time and input.
> 
> Best regards,
> Yifan Ji
> 
---end quoted text---