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

[Hao Jia <jiahao.kernel@gmail.com>]

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