Re: [PATCH 0/2] mm: zswap: free cold writeback folios promptly

[Yosry Ahmed]

On Sat, Jul 18, 2026 at 2:37 AM Alexandre Ghiti <alex@xxxxxxxx> wrote:
>
> When zswap writes an entry back, it allocates an order-0 swap cache folio,
> decompresses into it, and issues the write. The folio is cold by
> construction, yet today it is left on the LRU for page reclaim to find and
> free later. That wastes a reclaim scan and keeps cold memory resident
> longer than necessary.
>
> Free the folio as soon as writeback completes instead:
>
>   Patch 1 - synchronous-IO devices (zram, brd, pmem, ...) complete writeback
>             in the calling context, so the folio is freed directly there.
>
>   Patch 2 - asynchronous block devices and filesystem-backed swap complete
>             writeback in IRQ/softirq context, where the folio cannot be
>             freed (that needs the folio and swap cluster locks and may
>             sleep). Allocate the folio off the LRU and defer the free to a
>             workqueue, which folio_end_writeback() hands it off to.

I took a quick look through the patches and the implementation seems
too zswap-specific.

I am not super familiar with how the drop-behind mechanism works in
general, but it seems like it's currently intended for file pages and
not swap-backed pages. From a high-level perspective, it seems like we
should add support for swap dropbehind in general first (regardless of
zswap), e.g. by making folio_end_dropbehind() properly handle them,
and then have zswap opt into this?

I guess one of the challenges is that folio_end_dropbehind() only
frees folios in task context while we need to support interrupt
context, but this also doesn't seem like something that should be
handled in zswap.

In theory, there may be a use case for doing dropbehind for swap in
general, right?