Re: [RFC PATCH 0/1] mm/swap: keep reclaim batches contiguous on swap

[Alexandre Ghiti]

On Mon, Nov 2, 2026 at 5:20 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> >
> On Mon, Nov 2, 2026 at 5:42 PM Alexandre Ghiti <alexghiti@xxxxxxxx> wrote:
> >
> > Hi Kairui,
> >
> > Back from holidays, sorry for the late answer.
>
> Hello, hope you had a great holiday :D
>
> > On Mon, Oct 26, 2026 at 2:38 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
> > >
> > > >
> > > On Fri, Oct 23, 2026 at 12:17 AM Alexandre Ghiti <alexghiti@xxxxxxxx> wrote:
> > > >
> > > > Hi Kairui,
> > > >
> > > > On Thu, Oct 22, 2026 at 5:27 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
> > > > > Perhaps we should instead always scan the full clusters and revert
> > > > > that one commit? That commit was only following the idea of keeping
> > > > > the allocation more compacted for that series, it looked good at that
> > > > > time. Since fragmentation issues can be solved in other ways,
> > > > > contiguity seems to matter more for large physical swap devices.
> > > > >
> > > > Oh, okay. I thought reverting it wasn't an option given the good
> > > > numbers the patch provides.
> > >
> > > That patch is 1/3 of a series, that series yields really nice
> > > results, but that one patch plays only a small part in them. Or
> > > perhaps we can limit that to SYNC devices?
> >
> > I'm a bit scared it would not help zswap with writeback on, unless you
> > mean actual SWP_SYNCHRONOUS_IO devices?
>
> I mean maybe we can just scan nonfull first for SWP_SYNCHRONOUS_IO
> devices? These devices are less sensitive to discretely distributed
> I/O. For other devices we then prefer to keep the IO pattern
> continuous by using free clusters first.
>
> That may just fix the issue you are facing?
>
> Or maybe some threshold or quick scan in partial_free_cluster before
> putting the cluster back to nonfull.?

I can work on that as a follow up if you want, I'll take a look anyway.

Thanks again!

Alex