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

[Yosry Ahmed]

On Fri, Jul 24, 2026 at 12:35 PM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxx> wrote:
> > >
> > > On Fri, Jul 24, 2026 at 10:57 AM Yosry Ahmed <yosry@xxxxxxxxxx> 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.

Oh I was talking about going from no batching to batch=32. pspwin
increased by 387,400 (~30%). We are writing back 272,880 more pages
but we also have 209,837 less store rejections. So overall ~ 63,043
more pages should end up on disk, which doesn't explain the increase
in pspwin.

The only explanation I can think of is that the test is just randomly
accessing memory, so it ends up accessing colder memory that we moved
to disk more than hotter memory that we kept in zswap. IOW, the access
patterns do not conform to a "normal" workload that benefits from the
LRU.