Re: [PATCH 0/5] allocate extent_buffer GFP_NOFAIL with unlocked retry

On Tue, 2026-06-23 at 15:35 -0700, Boris Burkov wrote:
> From sampled fleet data measuring lock holders that go into direct
> reclaim with a waiter present when they eventually unlock, we have
> observed ~15% of those are btrfs extent_buffer allocations in
> btrfs_search_slot() done while holding btree locks. This is the single
> largest category. Additionally, a large source of hung_task timeouts is
> both btree waiters and direct reclaiming btree allocations, which
> further motivates the desire to drive down this source of stalls and
> contention.
> 
> The aim of this series is to allow us to allocate the extent_buffer,
> btrfs_folio_state, and the extent_buffer folios with GFP_NOWAIT then
> fallback with EAGAIN to outside the critical section to retry with
> GFP_NOFS | GFP_NOFAIL without any locks held.
> 
> This is analogous to how we must drop locks to read an extent_buffer and
> then EAGAIN.
> 
> The series does not manage to completely eliminate allocations from this
> lock holding path, as we also allocate inside xarray functions for the
> extent_buffer xarray and the btree_inode mapping xarray, the latter of
> which is done via filemap_add_folio() with no reserve type API. Luckily,
> those particular allocations are small cached slab allocations and have
> nearly no contribution to the production reclaim fueled contention.
> 
> Boris Burkov (5):
>   btrfs: factor init_extent_buffer from __alloc_extent_buffer
>   btrfs: add struct btrfs_eb_prealloc
>   btrfs: enable unlocked NOFAIL retry for eb allocations
>   btrfs: probe with GFP_NOWAIT for tree block readahead
>   btrfs: use GFP_NOWAIT when inhibiting eb writeback
> 
>  fs/btrfs/ctree.c       |  36 ++++++-
>  fs/btrfs/disk-io.c     |   6 +-
>  fs/btrfs/disk-io.h     |   2 +
>  fs/btrfs/extent-tree.c |   6 +-
>  fs/btrfs/extent_io.c   | 224 ++++++++++++++++++++++++++++-------------
>  fs/btrfs/extent_io.h   |  23 +++++
>  fs/btrfs/subpage.c     |   7 +-
>  fs/btrfs/subpage.h     |   3 +-
>  fs/btrfs/tree-log.c    |   3 +-
>  9 files changed, 226 insertions(+), 84 deletions(-)

Nice work, Boris! This all looks good to me. You can add:

    Reviewed-by: Jeff Layton <[email protected]>

Note that LLM review noted a couple of minor nits you might want to
address if/when you post a v2:

  - [N1] Dead code: commit 3 repoints the wrapper's only caller to the _prealloc variant, so
  btrfs_insert_delayed_dir_index() (kept "to preserve behavior" in commit 2) ends the series with
  zero callers in-tree. Suggest removing it + its prototype in commit 3 or a follow-up.

  - [N2] Latent (unreachable) leak: in btrfs_insert_dir_item, a non-NULL prealloc with
  need_delayed_index == false is neither committed nor freed. Only btrfs_rename passes a prealloc
  and its root is never tree_root, so it can't fire today — a defensive else if (prealloc) free
  would harden it.