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

[Hao Jia]

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?

Thanks,
Hao

> >                                 Baseline      Patched
> > shrink_worker wakeups         5,363            85
> > shrink_memcg calls       11,373,201      180,928
> > written_back pages            40,212       40,236
> > zswap_store calls            161,190      168,741
> >     store succeeded (ret=1)    102,743      127,644
> >     store rejected (ret=0)      58,447       41,097
> >     store reject rate            ~36%         ~24%
> > pool_limit_hit delta          55,826       14,062
> > pswpout                       98,659       81,333
> > pswpin                            2            1
> >
> >
> > Thanks,
> > Hao