From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Rik van Riel <riel@surriel.com>,
dsterba@suse.cz, Boris Burkov <boris@bur.io>,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
linux-mm@kvack.org, david@kernel.org, surenb@google.com,
hannes@cmpxchg.org, ljs@kernel.org, ziy@nvidia.com,
usama.arif@linux.dev, fvdl@google.com, Chris Mason <clm@meta.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH 34/40] btrfs: allocate eb-attached btree pages as movable
Date: Sun, 24 May 2026 23:57:42 -0700 [thread overview]
Message-ID: <ahPy5sZfkqwkB1FT@infradead.org> (raw)
In-Reply-To: <ahNYjY1aQlgOehlm@casper.infradead.org>
On Sun, May 24, 2026 at 08:59:09PM +0100, Matthew Wilcox wrote:
> Every use of GFP_NOFS is a bad code smell. Filesystems should be using
> memalloc_nofs_save/restore. The problem is that it takes deep filesystem
> knowledge to understand where the memalloc_nofs_save() should start.
> It would be good to lift the GFP_NOFS to the callers of this function as
> it gets us slightly closer to being able to replace it with GFP_KERNEL
> in the places it's not actually needed.
>
> ie what I'm asking for is, please don't do the 'extra_gfp' thing.
> Just pass in gfp from the callers and make them all pass in GFP_NOFS |
> __GFP_MOVABLE (or a plain GFP_NOFS) for now. Someone can come along
> later and change them to GFP_KERNEL later where warranted.
Note that is should be pretty trivial to just bubble it up a layer
for changes like this. This will naturally gravitate to more useful
places. To make it fully correct it will need manual intervention,
but generally bubbling up should improve the situation.
Same for GFP_NOIO.
next prev parent reply other threads:[~2026-05-25 6:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260520150018.2491267-1-riel@surriel.com>
2026-05-20 14:59 ` [RFC PATCH 34/40] btrfs: allocate eb-attached btree pages as movable Rik van Riel
2026-05-20 17:47 ` Boris Burkov
2026-05-23 15:58 ` David Sterba
2026-05-24 1:43 ` Rik van Riel
2026-05-24 19:59 ` Matthew Wilcox
2026-05-25 6:57 ` Christoph Hellwig [this message]
2026-05-21 7:39 ` [syzbot ci] Re: mm: reliable 1GB page allocation syzbot ci
2026-06-27 9:28 ` [RFC PATCH 00/40] " Lorenzo Stoakes
2026-06-27 13:36 ` Rik van Riel
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=ahPy5sZfkqwkB1FT@infradead.org \
--to=hch@infradead.org \
--cc=boris@bur.io \
--cc=clm@meta.com \
--cc=david@kernel.org \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=fvdl@google.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=riel@surriel.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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