Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg()

From: Yosry Ahmed

Date: Fri Jul 17 2026 - 12:56:19 EST


On Fri, Jul 17, 2026 at 9:50 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Thu, Jul 16, 2026 at 1:35 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> >
> > It is a bit alarming that the store rejection rate is still 43% with
> > batching, but we can worry about this later :)
>
> Yeah I think it's unavoidable at the time the global shrinker is
> awaken, unfortunately :( We need to kick off shrinking way ahead of
> time if we want to avoid this, especially since the rate of zswap out
> is going to be faster than the rate of writeback (CPU vs IO).
>
> Sort of why we implement the proactive reclaimers :)

Arguably, reclaim should wait for zswap writeback and retry, similar
to how allocators wakeup kswapd and retry, instead of just skipping
zswap. I was actually thinking about doing this at least for the memcg
limit case, eliminate the sync shrink_memcg(1) call in zswap_store()
and instead wakeup an async flusher and sleep.

A problem for another day I guess :)