Re: [RFC PATCH 0/1] mm/swap: keep reclaim batches contiguous on swap
From: Kairui Song
Date: Mon Nov 02 2026 - 12:39:32 EST
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.?