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

[Yosry Ahmed]

On Thu, Jul 2, 2026 at 5:32 AM Hao Jia <jiahao.kernel@xxxxxxxxx> wrote:
>
>
>
> 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.

Hmm this is actually a bit concerning. Yes, we are invoking the
shrinker less, but we're writing back *a lot* more memory, orders of
magnitude more. We are using a batch size of 64, and making ~1/3 of
the calls to shrink_memcg(), so the number of written back pages
should be ~20x more, not 3000x more? I think I am missing something.

Also, ideally, the batching wouldn't result in significantly more
writeback, but a similar amount of writeback over less shrinker
invocations. If we are writing back significantly more pages then the
batching logic is probably too aggressive?