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

在 2026/7/24 03:58, Boris Burkov 写道:
> 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?
> 

It is definitely sashiko, the base seems to be updated infrequently so 
that sometimes it didn't properly get the refreshed base and failed to 
apply.