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

[Johannes Weiner <hannes@cmpxchg.org>]

On Fri, Jul 24, 2026 at 11:39:41AM -0700, Yosry Ahmed wrote:
> On Fri, Jul 24, 2026 at 11:37 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Fri, Jul 24, 2026 at 10:57 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > >
> > > The numbers generally look good, the store rejection rate is
> > > decreasing and we are naturally doing more writeback which makes
> > > sense. The store rejection rate actually increases when the batch size
> > > increases to 64, maybe aggressive writeback is more likely to fail and
> > > cause a store rejection, so that also makes sense.
> > >
> > > The only part I can't immediately reason about is pswpin. How are we
> > > reading from physical swap more than we ever wrote to it?
> >
> > The same page can be swapped out once, and swap in multiple times :)
> >
> > Unlike zswap, physical swap in is not necessarily exclusive. You load
> > the page in memory, but if the swapfile is not full, etc. etc. you
> > don't invalidate the copy of the data on the swapfile. At reclaim
> > time, we notice the page is not dirty, so we just skip (z)swapout.
> 
> Oh right, I forgot about that, thanks.
> 
> I still don't fully understand why pswpin is significantly increased
> with batching here. I would hope that with less LRU inversion we end
> up with less disk swapin. Probably the test access patterns are just
> too random compared to real workloads?

Maybe more time in zswap for those tail entries left behind with the
smaller batch?

That's a 32 entry window that could zswpin with the smaller batch but
pswpin with the larger one.