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

[Yosry Ahmed]

On Tue, Jul 28, 2026 at 8:52 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Tue, Jul 28, 2026 at 4:22 AM Hao Jia <jiahao.kernel@xxxxxxxxx> wrote:
> >
> >
> > On 2026/7/28 00:18, Yosry Ahmed wrote:
> > Apologies—there was a flaw in my previous test setup. I had configured
> > zswap.max=320M alongside max_pool_percent=1. Since the global zswap pool
> > capacity was roughly 314M (< 320M), the global pool limit was actually
> > being hit before the cgroup zswap.max limit. Both limits were likely
> > interleaving throughout the run, making the results difficult to analyze.

Thanks for running the numbers again, these do look better!

> >
> > Re-running with **zswap.max=280M** yields results that align with
> > expectations:
> >
> > Test Case: zmax280 stress-4 pool1%
> >                              baseline        batch-all32      batch-all64
> >    shrink_worker wakeups            0                0                0
> >    shrink_memcg calls         698,990           57,187           29,649
> >    written_back               655,570          865,131          883,508
> >    store succeeded          1,054,928        1,124,990        1,190,608
> >    store rejected             229,722           22,642           11,659
> >    store reject rate             ~17%              ~1%              ~0%
> >    reject_reclaim_fail            110           15,454           12,985
> >    pswpout                    885,437          888,027          895,478
> >    pswpin                   2,035,415        1,305,341        1,384,751
> >    zswpout                  1,054,928        1,124,990        1,190,608
> >    zswpin                     280,675          162,684          158,556
> >
> > To isolate the cgroup zswap limit, I also tested with
> > max_pool_percent=50 (which should behave similarly to the zswap.max=280M
> > case above, bounded strictly by cgroup zswap.max):
> >
> > Test Case: zmax320 stress-4 pool50%
> >                             baseline        batch-all32      batch-all64
> >    shrink_worker wakeups            0                0                0
> >    shrink_memcg calls         687,608           54,002           28,116
> >    written_back               639,176          846,663          862,347
> >    store succeeded            992,816        1,208,123        1,213,286
> >    store rejected             231,431           20,425           10,915
> >    store reject rate             ~18%              ~1%              ~0%
> >    pswpout                    870,745          867,360          873,553
> >    pswpin                   1,707,823        1,216,814        1,378,381
> >    zswpout                    992,816        1,208,123        1,213,286
> >    zswpin                     250,220          210,791          185,716
> >
> >
> > Finally, here is the dataset for zswap.max=320M and max_pool_percent=1
> > with a single stress-ng worker (stress-1), which also looks consistent
> > with your expectations:
> >
> > Test Case: zmax320 stress-1 pool1%
> >                            baseline        batch-all32      batch-all64
> >    shrink_worker wakeups        9,279              980              557
> >    shrink_memcg calls      14,247,647        2,638,751        1,465,915
> >    written_back                 7,702          439,809          482,809
> >    store succeeded            329,603          531,224          566,150
> >    store rejected             883,945          517,578          482,644
> >    store reject rate             ~73%             ~49%             ~46%
> >    pswpout                    891,647          957,388          965,453
> >    pswpin                     692,255          628,246          582,781
> >    zswpout                    329,603          531,224          566,150
> >    zswpin                     248,871                3            7,872
>
> Shall we just go with SWAP_CLUSTER_MAX per Johannes' suggestion then?
> 32 works the best here FWIW, but seems like it's all relatively good
> (as long as it's not 1).

Yeah I think so, the less magic macros the better.

>
> (I wonder if this works well with your proactive reclaimer too but we
> shall see).