Re: [RFC PATCH 0/4] mm/zswap: make shrinker writeback work with iocost

[Nhat Pham]

On Mon, Sep 28, 2026 at 9:19 AM Alexandre Ghiti <alex@xxxxxxxx> wrote:
>
> We want to enable the zswap shrinker on our fleet, which runs iocost,
> but with it on, a large production workload is slower than with it
> off. Two reasons:
>
> 1. zswap writeback is REQ_SWAP, so the IO controllers issue it as root
>    and charge it to the cgroup afterwards, as debt. The workload pays it
>    back: its swapin and page cache reads wait, and iocost eventually
>    stalls its allocations, which in turn stalls the application.
>    Patches 1-3 let zswap writeback be throttled instead, by marking it
>    REQ_BACKGROUND.
>
> 2. A throttled write sleeps in its submitter, which for the shrinker is
>    whoever entered reclaim, often an application thread in a page fault.
>    Patch 4 moves that writeback to a per-lruvec kworker.

Yeah that tracks with an older experiment of mine, where I add some
manual throttling to zswap shrinker to reduce latency :) So I think
this problem is real - thanks for root-causing this, Alex!

I'm a bit nervous about adding multiple kworker threads though, hmmm.
Per-lruvec sounds like a lot of threads... Do we have to scale this by
lruvec? Why not per-cpu, or just a global thread? Is there any data to
support this autoscaling?

And do we have any concerns with work (CPU) accounting, from a cgroup
perspective...?