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

On Tue, Jul 21, 2026 at 03:42:11PM -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.
> 
> Changelog:
> v2: 
> - rebase
> - dropped the inhibit array allocation patch

Reviewed-by: David Sterba <[email protected]>

The logic makes sense to avoid the stalls. There's no sashiko review
because the patches did not apply. You may want to resend a rebased
version to see if I have missed something, there are minor typos or
style things but that can be fixed during merge.