Re: [PATCH v2 3/3] mm: zswap: drop cold writeback folios via swap dropbehind
From: Nhat Pham
Date: Tue Jul 28 2026 - 12:19:23 EST
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.)