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

[Salvatore Dipietro]

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.

I'm happy to test any additional variations or direction to move this forward

--
Salvatore





AMAZON DEVELOPMENT CENTER ITALY SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2504859, Capitale Sociale: 10.000 EUR i.v., Cod. Fisc. e P.IVA 10100050961, Societa con Socio Unico