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

[Hao Jia]

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