Re: [PATCH 1/2] mm: zswap: free synchronous-IO writeback folios directly

[Nhat Pham]

On Thu, Jul 23, 2026 at 6:39 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> On Sat, Jul 18, 2026 at 11:36:39AM +0200, Alexandre Ghiti wrote:
>
> I just chatted with Alexandre off-list, but this path does not store
> an eviction shadow like the reclaim path does. That means no refaults
> are detected from dropbehind pages, which can fundamentally alter
> reclaim decisions, zswap shrinker force, and pressure detection.

I think it's a zswap shrinker bug even before this patch. When we
allocate a new buffer for the writeback request and add to swap cache,
we erase the old shadow :(

I had a patch sometimes ago to fix this - basically, what it did is
when we allocate the buffer for writeback and add it to swap cache, we
save the existing shadow and hand that shadow to zswap. zswap will
store it in the zswap tree tree (in place of the struct zswap entry
that is being freed).

Now you will have to juggle it a bit in various path:

1. swapin has to check the zswap tree for refault.

2. remove_mapping does not create a new shadow, but instead restore
the zswap's owned shadow, if there is one.

3. zswap operations have to now handle shadows stored in its trees too.

I think there is one edge case where we still lose the old shadow (I
need to check), but the rest seems to work.

It's a bit complex, yes, but I managed to find more uses for this
added complexity too. With this, I was able to add more monitoring to
zswap shrinker - you can track how many shadows are being stored in
the zswap tree, which gives you a per-cgroup counter of inflight zswap
buffers. This helps with diagnosing when zswap writeback is generating
too much memory pressure with these buffers. You can also use this
counter it for zswap writeback heuristics (for instance, throttle
writeback when there are too many inflight buffers already and we're
not freeing them fast enough).

I have not had the chance to make it upstream-ready, given all of my
attention being taken away by vswap and other endeavors, and the fact
that swap architecture has changed quite a bit.