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

[Salvatore Dipietro]

On Sat, May 31, 2026 at 11:29:00PM +0000, Karim Manaouil wrote:
> I am not very familiar with THPs in the page cache, but for anonymous
> memory, we have /sys/kernel/mm/transparent_hugepages/defrag which
> decides what to do in the event of a THP allocation failure, whether to
> enter a synchronous compaction or wake up kcompactd.

Thanks Karim for the suggestions. To clarify, THPs are not used and do not 
have any performance change on this workload as reported in [1]. 
The failing allocations are for high order file-backed folios in the 
iomap buffered write path.

> I am just trying to think loudly here and address the root cause. The
> real problem here is fragmentation due to unmovable pages, probably in
> your case the page tables. We should work more on reducing pageblock
> type mixing. Also page tables can actually be made movable so that
> compaction can treat them as movable pages.

I agree that making PTEs movable could potentially resolve the
fragmentation at its root, since page table pages are indeed the primary
source of unmovable fragmentation in this workload. However, making page 
tables movable has much broader implications.


[1] https://lore.kernel.org/all/20260428150240.3009-1-dipiets@xxxxxxxxx/

--
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