Re: [PATCH v2 3/3] mm: zswap: drop cold writeback folios via swap dropbehind

[Yosry Ahmed]

On Tue, Jul 28, 2026 at 8:48 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Tue, Jul 28, 2026 at 5:58 AM Alexandre Ghiti <alexghiti@xxxxxxxx> wrote:
> >
> > Hi Yosry,
> >
> > On Mon, Jul 27, 2026 at 7:05 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > >
> > > >
> > > On Mon, Jul 27, 2026 at 7:39 AM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> > > >
> > > > zswap writeback decompresses an entry into a fresh swap cache folio and
> > > > writes it back. The folio is cold by construction, yet it is left on the
> > > > LRU for reclaim to find and free later, wasting a reclaim scan and keeping
> > > > cold memory resident longer than necessary.
> > > >
> > > > Allocate the folio off the LRU and drop it as soon as writeback completes:
> > > > mark it PG_dropbehind so the swap dropbehind path frees it once writeback
> > > > ends. Synchronous-IO devices complete writeback in this context, so there
> > > > the folio is dropped inline instead.
> > >
> > > Why does this need to be handled in zswap? Doesn't writeback from sync
> > > devices still call folio_end_writeaback() and do the dropbehind
> > > handling?
> >
> > That's an optimization rather than a real need: since we know we are
> > in a sleepable context, we can safely drop the folio from the swap
> > cache here. And since we don't mark the sync folios as dropbehind,
> > they never enter the list handled by the dropbehind workqueue.
>
> It's a bit artificial, but you can try testing zswap writeback to
> zram? :) Likely you'll see some small tput win there?
>
> (TBH I have not seen sync IO swap backends other than zram though so
> idk what's more realistic. We don't have pmem device available for
> testing etc.)

I don't think it's worth optimizing zswap + sync backend tbh.