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

[Kairui Song]

On Wed, Jul 22, 2026 at 10:41 AM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> On Sat, Jul 18, 2026 at 5:38 PM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> >
> > For synchronous-IO swap devices writeback completes in the calling context,
> > so the folio can be freed right after the write rather than left behind; do
> > that. Because it is freed directly rather than through reclaim, it is
> > allocated off the LRU: dropping the last reference on a folio still on the
> > LRU would trip the free-time page-flag checks. A folio that a concurrent
> > swapin has meanwhile claimed is left in place and reclaimed as usual.
> >
> > Asynchronous and filesystem-backed swap complete writeback in interrupt
> > context, where the folio cannot be freed; they are handled in a later
> > change.
>
> Might be a bit off-topic, but I've been thinking about this problem
> for a while.
>
> MADV_PAGEOUT, and reclaim in general, don't actually free memory
> when using asynchronous swap devices. Do you think it would make
> sense to free the folio directly, at least for anonymous folios,
> once it has been written out, instead of waiting for another reclaim
> scan?
>
> It seems a bit odd that after MADV_PAGEOUT completes, the memory is
> still occupied.

Yes but I think that immediate drop might be actually better be
limited to things like MADV_PAGEOUT and zswap cold writeback? For
common swap, keeping the swap cache after writeback sometimes helps a
lot by catching fast refaults. Because we perform swap writeback
asynchronously, we can easily overshoot the reclaim and send more
folios into writeback than necessary.

For direct synchronous IO devices or direct zswap compression that's
not a problem because their writeback is synchronized, so the
reclaimer waits. And we already free them immediately after writeback.