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

[Hao Jia]

On 2026/7/17 02:04, Nhat Pham wrote:
> On Wed, Jul 15, 2026 at 7:54 PM Hao Jia <jiahao.kernel@xxxxxxxxx> wrote:
> > On 2026/7/16 00:14, Yosry Ahmed wrote:
> > > > > > Test Setup:
> > > > > > Total memory: 32 GB.
> > > > > > zswap settings: max_pool_percent=1, accept_threshold_percent=50,
> > > > > > shrinker_enabled=N.
> > > > > > Allocate 512MB of anonymous pages and fill them with random data (to avoid
> > > > > > compression), then use cgroup memory.reclaim to force a large amount of
> > > > > > anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous
> > > > > > page where the first 4 bytes are random numbers and the rest are zeros, and
> > > > > > then trigger a reclamation of this 4K anonymous page through cgroup
> > > > > > memory.reclaim. When the pool threshold is reached, shrink_memcg() will
> > > > > > be triggered.
> > > > > >
> > > > > > The test data after running for 120s is as follows:
> > > > > >                               Baseline         Patched
> > > > > > shrink_worker wakeups          5363             85
> > > > > > shrink_memcg calls       11,345,012        188,264
> > > > > > written_back                  40214          40275
> > > > > >
> > > > > > Conclusion:
> > > > > > Under the same workload and run duration, the patched kernel shows a
> > > > > > significant reduction in both shrink_worker wakeups and shrink_memcg calls.
> > > > >
> > > > > Please also include data from the case where zswap store failures are
> > > > > observed and pages go to disk, and compare before and after this
> > > > > patch. I think that part is also really important.
> > > >
> > > > I retested and added some collected information. Perhaps
> > > > `pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap
> > > > can reduce the number of pages that fail to be stored due to the pool
> > > > limit, allowing zswap to skip zswap and go directly to disk.
> > >
> > > Oh I meant the other test case with high memory pressure where we saw
> > > a lot more writeback with this patch. Do you have similar data from
> > > that test case?
> >
> > Below are the results from stress-ng (high memory pressure case), which
> > lead to a similar conclusion:
> >
> >                                 Baseline      Patched
> > shrink_worker wakeups         5,640           987
> > shrink_memcg calls        8,481,500     2,504,818
> > written_back pages               260       768,576
> > zswap_store calls           2,742,756     2,301,414
> >     store succeeded (ret=1)     934,640     1,308,686
> >     store rejected (ret=0)    1,808,116       992,728 <-
> >     store reject rate            ~65%           ~43%
> > pool_limit_hit delta        1,181,310       101,593 <-
> > pswpout                     1,808,376     1,761,304
> > pswpin                      4,288,497     3,902,658
> >
> >
> > pswpout = store rejected + written_back pages
> > Note that pswpout comprises two parts: the store rejected count (where
> > we skip zswap and go directly to disk) and the number of pages written
> > back by shrink_memcg().
> >
> > Therefore, we can directly leverage store rejected to evaluate the
> > scenario where zswap is skipped and pages bypass it to disk. This
> > provides a much clearer picture than looking at pswpout alone.
> >
> > Do we need to include both sets of test results along with the
> > comparison data in the final commit message?
>
> I mean, it helps your case no? :)

Yes, I will add both sets of test results to the commit message in the 
next version.
> But nicely done. My understanding is, this batching of the global
> shrinker reduces overall disk swap fallback, correct?
>
> Other than Yosry's comment, the rest LGTM FWIW :) Thanks for fixing this, Hao!

Thanks for the review, Nhat!

Thanks,
Hao