Re: [PATCH v3 2/3] mm: swap: drop dropbehind swap cache folios on writeback completion

[Alexandre Ghiti]

Hi Barry,

On Thu, Aug 20, 2026 at 1:37 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> >
> On Wed, Aug 19, 2026 at 12:34 AM Alexandre Ghiti <alex@xxxxxxxx> wrote:
> >
> > A PG_dropbehind folio is dropped from its cache once writeback completes
> > rather than left for reclaim to find later; this is implemented for file
> > folios in folio_end_dropbehind(). Extend it to swap cache folios.
> >
> > The drop needs the folio and swap cluster locks and may sleep, but
> > writeback can complete in interrupt context, so defer the work to a
> > workqueue that runs once writeback has completed and frees the folios in
> > batches.
> >
> > Suggested-by: Yosry Ahmed <yosry@xxxxxxxxxx>
> > Suggested-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> > Suggested-by: Nhat Pham <nphamcs@xxxxxxxxx>
> > Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
> > ---
> [...]
> >
> > +static DEFINE_PER_CPU(struct llist_head, swap_dropbehind_llist);
> > +
> > +static bool swap_dropbehind_drop_folio(struct folio *folio)
> > +{
> > +       struct mem_cgroup *memcg;
> > +       bool dropped = false;
> > +
> > +       folio_lock(folio);
> > +
> > +       /* The folio was allocated off the LRU and nothing re-adds it here. */
> > +       VM_WARN_ON_ONCE_FOLIO(folio_test_lru(folio), folio);
>
> Hi Alexandre,
> Thanks very much for your patch!
>
> I don't quite understand why we only support NON-LRU folios. Does this
> restriction prevent potential optimizations for madv_pageout?

In the current implementation, I re-use folio->lru to link the
dropbehind folios for the worker to free, so folio->lru must not be
used, hence the folio_test_lru().

But that does not prevent madv_pageout to use dropbehind at all,
folios are isolated from the lru and moved to a private folio_list, we
can definitely prevent the latter if the folio is marked as
dropbehind.

I'll give it a try, I had only tried setting dropbehind on all swap
folios which caused large regressions.

>
> Also, zram might benefit from your patch in the future with
> asynchronous hardware compression and software compression such as
> kcompressd[1].
>

Thanks, I'll take a look.


> [1] https://lore.kernel.org/linux-mm/20250430082651.3152444-1-qun-wei.lin@xxxxxxxxxxxx/
>
> [...]
> > +
> > +/**
> > + * swap_dropbehind_free_batch_folio - free a dropbehind swap cache folio into a batch
> > + * @folio: the off-LRU folio whose writeback has completed
> > + * @fbatch: batch of folios to free, flushed when full
> > + */
> > +static void swap_dropbehind_free_batch_folio(struct folio *folio,
> > +                                            struct folio_batch *fbatch)
> > +{
> > +       if (swap_dropbehind_drop_folio(folio) && !folio_batch_add(fbatch, folio))
> > +               folios_put(fbatch);
> > +}
> > +
> > +static void swap_dropbehind_workfn(struct work_struct *work)
> > +{
> > +       struct folio_batch fbatch;
> > +       struct llist_node *pos, *next;
> > +       int cpu;
> > +
> > +       folio_batch_init(&fbatch);
> > +       for_each_possible_cpu(cpu) {
> > +               pos = llist_del_all(per_cpu_ptr(&swap_dropbehind_llist, cpu));
> > +               llist_for_each_safe(pos, next, pos) {
> > +                       struct folio *folio = container_of((struct list_head *)pos,
> > +                                                          struct folio, lru);
> > +                       swap_dropbehind_free_batch_folio(folio, &fbatch);
> > +               }
> > +       }
> > +       if (fbatch.nr)
> > +               folios_put(&fbatch);
> > +}
> > +
> > +static DECLARE_WORK(swap_dropbehind_work, swap_dropbehind_workfn);
> > +static struct workqueue_struct *swap_dropbehind_wq;
> > +
> > +void swap_writeback_dropbehind_folio(struct folio *folio)
> > +{
> > +       llist_add((struct llist_node *)&folio->lru,
> > +                 raw_cpu_ptr(&swap_dropbehind_llist));
> > +       queue_work(swap_dropbehind_wq, &swap_dropbehind_work);
> > +}
> > +
>
> This is good. For file dropbehind, I see both F2FS [1] and block
> devices [2] reinventing workqueues in their own filesystems or
> drivers, while folio_end_dropbehind() simply benefits from its safe,
> sleepable context. This seems a bit odd.

folio_end_dropbehind() is not always executed in a sleepable context,
that's why I only add the dropbehind folios to the list for the worker
(which executes in sleepable context) to free them.

But anyway, as Matthew pointed out, it seems like this patchset would
be way easier on top of [2], I'm looking into right now.

Thanks for your comments,

Alex

>
> So I'm really curious whether this could be extended to file-backed
> folios as well, so that those filesystems and device drivers don't
> have to deal with this themselves.
>
> [1] https://lore.kernel.org/all/20260820071438.695893-1-qiwenjie@xxxxxxxxxx/
> [2] https://lore.kernel.org/all/20260730-blk-dontcache-v7-2-3e8e6850068d@xxxxxxxxxxxx/
>
> Thanks
> Barry
>