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

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


Boris Burkov (4):
  btrfs: factor init_extent_buffer from __alloc_extent_buffer
  btrfs: add struct btrfs_eb_prealloc
  btrfs: enable unlocked NOFAIL retry for eb allocations
  btrfs: use GFP_NOWAIT for tree block readahead

 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   | 213 ++++++++++++++++++++++++++++-------------
 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, 220 insertions(+), 79 deletions(-)

-- 
2.55.0