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

Matthew Wilcox
2026-04-04T20:46:52Z

On Sat, Apr 04, 2026 at 10:17:33PM +0530, Ritesh Harjani wrote:
> Matthew Wilcox <willy@infradead.org> writes:
>
> > On Fri, Apr 03, 2026 at 07:35:34PM +0000, Salvatore Dipietro wrote:
> >> Commit 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")
> >> introduced high-order folio allocations in the buffered write
> >> path. When memory is fragmented, each failed allocation triggers
> >> compaction and drain_all_pages() via __alloc_pages_slowpath(),
> >> causing a 0.75x throughput drop on pgbench (simple-update) with
> >> 1024 clients on a 96-vCPU arm64 system.
> >>
> >> Strip __GFP_DIRECT_RECLAIM from folio allocations in
> >> iomap_get_folio() when the order exceeds PAGE_ALLOC_COSTLY_ORDER,
> >> making them purely opportunistic.
> >
> > If you look at __filemap_get_folio_mpol(), that's kind of being tried
> > already:
> >
> > if (order > min_order)
> > alloc_gfp |= __GFP_NORETRY | __GFP_NOWARN;
> >
> > * %__GFP_NORETRY: The VM implementation will try only very lightweight
> > * memory direct reclaim to get some memory under memory pressure (thus
> > * it can sleep). It will avoid disruptive actions like OOM killer. The
> > * caller must handle the failure which is quite likely to happen under
> > * heavy memory pressure. The flag is suitable when failure can easily be
> > * handled at small cost, such as reduced throughput.
> >
> > which, from the description, seemed like the right approach. So either
> > the description or the implementation should be updated, I suppose?
> >
> > Now, what happens if you change those two lines to:
> >
> > if (order > min_order) {
> > alloc_gfp &= ~__GFP_DIRECT_RECLAIM;
> > alloc_gfp |= __GFP_NOWARN;
> > }
>
> Hi Matthew,
>
> Shouldn't we try this instead? This would still allows us to keep
> __GFP_NORETRY and hence light weight direct reclaim/compaction for
> atleast the non-costly order allocations, right?
>
> if (order > min_order) {
> alloc_gfp |= __GFP_NOWARN;
> if (order > PAGE_ALLOC_COSTLY_ORDER)
> alloc_gfp &= ~__GFP_DIRECT_RECLAIM;
> else
> alloc_gfp |= __GFP_NORETRY;
> }

Uhh ... maybe? I'd want someone more familiar with the page allocator
than I am to say whether that's the right approach. If it is, that
seems too complex, and maybe we need a better approach to the page
allocator flags.