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

[Nhat Pham]

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.
>
> 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).

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