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

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

On 2026/7/17 02:04, Nhat Pham wrote:
> 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? :)

Yes, I will add both sets of test results to the commit message in the 
next version.
> 
> 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!

Thanks for the review, Nhat!

Thanks,
Hao