Re: [PATCH 1/1] iomap: avoid compaction for costly folio order allocation

[Christoph Hellwig <hch@infradead.org>]

On Wed, Jun 24, 2026 at 08:06:36AM +0000, Salvatore Dipietro wrote:
> 
> Hi Ritesh, Matthew,
> 
> I wanted to kindly follow up on my summary from May 27th regarding the best path 
> forward for this patch.
> 
> To recap, we benchmarked all proposed variations and shared the results:
> 
> | Patch                          | Change Location        | Avg TPS    | % vs Baseline |
> |--------------------------------|------------------------|------------|:-------------:|
> | Baseline (no patch)            | —                      | 101,979.75 |       —       |
> | v1 (original, iomap caller)    | fs/iomap/buffered-io.c | 141,194.20 |    +38.45%    |
> | Ritesh's suggestion            | mm/filemap.c           | 139,200.61 |    +36.50%    |
> | Matthew's suggestion           | mm/filemap.c           | 143,863.82 |    +41.07%    |
> | kcompactd background           | mm/page_alloc.c        | 134,278.47 |    +31.67%    |
> 
> I'd really appreciate any guidance on which direction would be acceptable for a v3 — 
> whether that's the page allocator approach (kcompactd background), one of the filemap.c
> fixes, or something else entirely.

Do you have ointers to the patches for each approach above?