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

[Alexandre Ghiti]

Hi Yosry,

On Mon, Jul 20, 2026 at 8:26 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> >
> 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?
>

Yes, you're right, I have been focused on zswap here but that should
be extended to swap in general.

I only have performance numbers for zswap though, so I need to verify
the impact on swap in general first.

Thanks,

Alex