Re: [PATCH v5 4/6] mm/zswap: Implement proactive writeback

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

On 2026/7/1 19:45, Hao Jia wrote:
> 
> 
> On 2026/7/1 00:10, Yosry Ahmed wrote:
>>>> Before going through more versions we need to figure out if this will
>>>> pivot to be a proactive demotion interfcae for swap tiering.
>>>>
>>>
>>> Yes. Should I drop patches 4-6 in the next version and wait for swap
>>> tiering to be finalized?
>>> We can try to get the non-memcg parts (patches 1-3) merged upstream
>>> first. This would also give them plenty of time to bake and catch any
>>> potential regressions. Thoughts?
>>
>> Patches 1-2 can be sent and merged separately, yes. For patch 2,
>> please include some numbers for the writeback performance before and
>> after batching.
> 
> I'd love to collect some performance data. Do you have any recommended 
> benchmarks for this?
> 

Perhaps the following test case could work?

Test Setup:
- Total memory: 32 GB
- zswap settings: max_pool_percent=1, accept_threshold_percent=50, 
shrinker_enabled=N
- cgroup constraint: memory.max=1G
- Workload: Run the following stress-ng command inside the cgroup for 
120s to
   continuously force zswap store failures and trigger shrink_worker():

   bash -c 'echo $$ > /sys/fs/cgroup/zswaptest/cgroup.procs ; \
   exec stress-ng --vm 4 --vm-bytes 4G --vm-keep --vm-method rand-set -t 
120s -q'

The following comparison results were collected over multiple runs via 
bpftrace
and the 'written_back_pages' sysfs interface:

                          Baseline         Patched
---------------------------------------------------
shrink_worker wakeups       5,587             878
shrink_memcg calls      7,823,853       2,347,320
written_back                  257         781,214

Conclusion:
Under the same workload and duration, the patched kernel shows a 
significant reduction
in both shrink_worker wakeups and shrink_memcg calls, while successfully 
executing a
much higher volume of page writebacks.

Thanks，
Hao