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

On Thu, Jul 23, 2026 at 04:58:57AM +0200, David Sterba wrote:
> 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.

Hmm, interesting. I rebased on the btrfs
([email protected]:btrfs/linux.git) for-next branch before resending, and
it just rebased cleanly, and I was able to 'b4 shazam' this version onto
for-next as well.

Am I messing up and using the wrong branch? Is sashiko?