From: Matthew Wilcox <willy@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Salvatore Dipietro <dipiets@amazon.it>,
linux-kernel@vger.kernel.org, ritesh.list@gmail.com,
abuehaze@amazon.com, alisaidi@amazon.com, blakgeof@amazon.com,
brauner@kernel.org, dipietro.salvatore@gmail.com,
djwong@kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-xfs@vger.kernel.org,
stable@vger.kernel.org, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v2] mm/filemap: avoid costly reclaim for high-order folio allocations
Date: Mon, 20 Apr 2026 19:41:03 +0100 [thread overview]
Message-ID: <aeZzP6iQel-tkZOu@casper.infradead.org> (raw)
In-Reply-To: <20260420095106.86ecdb685cd31e0847362512@linux-foundation.org>
On Mon, Apr 20, 2026 at 09:51:06AM -0700, Andrew Morton wrote:
> On Mon, 20 Apr 2026 16:14:03 +0000 Salvatore Dipietro <dipiets@amazon.it> wrote:
> > Commit 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")
> > introduced high-order folio allocations in the buffered write path.
No it didn't. 5d8edfb900d5 only allows the use of larger folios if they
already existed in the page cache. d6bb59a9444d allows the creation of
large folios.
> > When memory is fragmented, each failed allocation above
> > PAGE_ALLOC_COSTLY_ORDER 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.
Why are you pretending this is new instead of already being the source
of much recent discussion?
https://lore.kernel.org/all/20260403193535.9970-1-dipiets@amazon.it/
> "Good money after bad"? Prove me wrong!
>
> Instead of performing weird fragile hard-to-maintain party tricks with
> the page allocator to work around the damage, plan B is to simply
> revert 5d8edfb900d5.
lol. best of luck with that. you'd break a lot of other things if you
did.
> 5d8edfb900d5 came with no performance testing results. Does anyone
> have any evidence that it improved anything? By how much?
Christoph reported it doubled write performance with NFS once NFS was
converted to use it.
next prev parent reply other threads:[~2026-04-20 18:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 16:14 Salvatore Dipietro
2026-04-20 16:51 ` Andrew Morton
2026-04-20 18:41 ` Matthew Wilcox [this message]
2026-04-20 19:12 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aeZzP6iQel-tkZOu@casper.infradead.org \
--to=willy@infradead.org \
--cc=abuehaze@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=alisaidi@amazon.com \
--cc=blakgeof@amazon.com \
--cc=brauner@kernel.org \
--cc=dipietro.salvatore@gmail.com \
--cc=dipiets@amazon.it \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox