mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] mm/swap: submit the last readahead batch before unplugging
@ 2026-10-01  8:57 Alexandre Ghiti
  2026-10-01  9:52 ` Joshua Hahn
  0 siblings, 1 reply; 3+ messages in thread
From: Alexandre Ghiti @ 2026-10-01  8:57 UTC (permalink / raw)
  To: Andrew Morton, linux-mm
  Cc: Christoph Hellwig, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
	Baoquan He, Barry Song, Youngjun Park, linux-kernel,
	Alexandre Ghiti

Since block swap I/O is batched in struct swap_iocb, swap_add_folio()
only appends a folio to the pending batch when its slot directly follows
the previous one, and submits the pending batch otherwise. Batches
submitted inside the readahead loop go through the plug, where the block
layer can still merge them, but the final batch is submitted after
blk_finish_plug() and always becomes a separate request.

So submit the final batch before finishing the plug.

Fixes: dda8fb68b590 ("mm/swap: also use struct swap_iocb for block I/O")
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
---
 mm/swap_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/swap_state.c b/mm/swap_state.c
index 2475ba29126d..ebef568cd62e 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -906,8 +906,8 @@ struct folio *swap_cluster_readahead(swp_entry_t entry, gfp_t gfp_mask,
 			continue;
 		folio_put(folio);
 	}
-	blk_finish_plug(&plug);
 	swap_read_submit(&ctx);
+	blk_finish_plug(&plug);
 skip:
 	return swap_cache_read_folio_sync(entry, gfp_mask, mpol, ilx);
 }
@@ -1019,8 +1019,8 @@ static struct folio *swap_vma_readahead(swp_entry_t targ_entry, gfp_t gfp_mask,
 	}
 	if (pte)
 		pte_unmap(pte);
-	blk_finish_plug(&plug);
 	swap_read_submit(&ctx);
+	blk_finish_plug(&plug);
 skip:
 	/* The folio was likely read above, so no need for plugging here */
 	return swap_cache_read_folio_sync(targ_entry, gfp_mask, mpol, targ_ilx);
-- 
2.53.0-Meta


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm/swap: submit the last readahead batch before unplugging
  2026-10-01  8:57 [PATCH] mm/swap: submit the last readahead batch before unplugging Alexandre Ghiti
@ 2026-10-01  9:52 ` Joshua Hahn
  2026-10-02  1:16   ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Joshua Hahn @ 2026-10-01  9:52 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Andrew Morton, linux-mm, Christoph Hellwig, Chris Li,
	Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
	Youngjun Park, linux-kernel

On Thu,  1 Oct 2026 10:57:12 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:

> Since block swap I/O is batched in struct swap_iocb, swap_add_folio()
> only appends a folio to the pending batch when its slot directly follows
> the previous one, and submits the pending batch otherwise. Batches
> submitted inside the readahead loop go through the plug, where the block
> layer can still merge them, but the final batch is submitted after
> blk_finish_plug() and always becomes a separate request.
> 
> So submit the final batch before finishing the plug.

Hi Alex,

I read through the code and this looks very reasonable to me.

Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

> Fixes: dda8fb68b590 ("mm/swap: also use struct swap_iocb for block I/O")

My only question is whether we need the fixes tag, it seems like
dda8fb68b590 is still in mm-stable and not merged to linus yet.

Andrew, what do we usually do in these cases? I am wondering if it will
just become folded into the original commit or if this should still be
standalone.

Thank you both! Have a great day : -)
Joshua

> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
> ---
>  mm/swap_state.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 2475ba29126d..ebef568cd62e 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -906,8 +906,8 @@ struct folio *swap_cluster_readahead(swp_entry_t entry, gfp_t gfp_mask,
>  			continue;
>  		folio_put(folio);
>  	}
> -	blk_finish_plug(&plug);
>  	swap_read_submit(&ctx);
> +	blk_finish_plug(&plug);
>  skip:
>  	return swap_cache_read_folio_sync(entry, gfp_mask, mpol, ilx);
>  }
> @@ -1019,8 +1019,8 @@ static struct folio *swap_vma_readahead(swp_entry_t targ_entry, gfp_t gfp_mask,
>  	}
>  	if (pte)
>  		pte_unmap(pte);
> -	blk_finish_plug(&plug);
>  	swap_read_submit(&ctx);
> +	blk_finish_plug(&plug);
>  skip:
>  	/* The folio was likely read above, so no need for plugging here */
>  	return swap_cache_read_folio_sync(targ_entry, gfp_mask, mpol, targ_ilx);
> -- 
> 2.53.0-Meta

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm/swap: submit the last readahead batch before unplugging
  2026-10-01  9:52 ` Joshua Hahn
@ 2026-10-02  1:16   ` Andrew Morton
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2026-10-02  1:16 UTC (permalink / raw)
  To: Joshua Hahn
  Cc: Alexandre Ghiti, linux-mm, Christoph Hellwig, Chris Li,
	Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
	Youngjun Park, linux-kernel

On Thu,  1 Oct 2026 02:52:33 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Thu,  1 Oct 2026 10:57:12 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
> 
> > Since block swap I/O is batched in struct swap_iocb, swap_add_folio()
> > only appends a folio to the pending batch when its slot directly follows
> > the previous one, and submits the pending batch otherwise. Batches
> > submitted inside the readahead loop go through the plug, where the block
> > layer can still merge them, but the final batch is submitted after
> > blk_finish_plug() and always becomes a separate request.
> > 
> > So submit the final batch before finishing the plug.
> 
> Hi Alex,
> 
> I read through the code and this looks very reasonable to me.
> 
> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Thanks.

> > Fixes: dda8fb68b590 ("mm/swap: also use struct swap_iocb for block I/O")
> 
> My only question is whether we need the fixes tag, it seems like
> dda8fb68b590 is still in mm-stable and not merged to linus yet.
> 
> Andrew, what do we usually do in these cases? I am wondering if it will
> just become folded into the original commit or if this should still be
> standalone.

dda8fb68b590 was added to 7.3.rc1 during the most recent merge window.

So the Fixes: is appropriate - if someone chooses to merge dda8fb68b590
into their downstream kernel we're telling them "hey, you need this one
as well".


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-02  1:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-01  8:57 [PATCH] mm/swap: submit the last readahead batch before unplugging Alexandre Ghiti
2026-10-01  9:52 ` Joshua Hahn
2026-10-02  1:16   ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®