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

[Nhat Pham <nphamcs@gmail.com>]

On Wed, Jul 15, 2026 at 7:54 PM Hao Jia <jiahao.kernel@gmail.com> 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? :)

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!