linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/17] btrfs: restrain lock extent usage during writeback
@ 2024-04-17 14:35 Josef Bacik
  2024-04-17 14:35 ` [PATCH 01/17] btrfs: handle errors in btrfs_reloc_clone_csums properly Josef Bacik
                   ` (17 more replies)
  0 siblings, 18 replies; 45+ messages in thread
From: Josef Bacik @ 2024-04-17 14:35 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

Hello,

We use the extent lock to cover a pretty wide range of operations during
writeback, and this has made things like the iomap conversion more annoying.
It's also relatively complex how the rules work, and in fact are different
between compressed and normal writeback.

This series is meant to address this by pushing the extent lock down to cover a
discreet set of operations.  Being able to clearly define what the extent lock
is protecting will give us a better idea of how to reduce it's usage or possibly
replace it in the future.

The current state of affairs has been we lock the page for the range we're going
to write back, and then we lock the extent, and then we start writeback.  This
looks a few different ways

COW:
lock page
  lock extent
    allocate the extent
    insert the pinned extent
    allocate the ordered extent
    clear DELALLOC
  unlock extent
unlock page

NOCOW
lock page
  lock extent
    lookup the file extent
      check if the file extent can be used nocow
        if no:
          cow_file_range
        if yes:
          insert pinned extent if prealloc
          allocate ordered extent
          clear delalloc
  unlock extent
unlock page

COMPRESS
lock page
  lock extent
  unlock extent
    create async objects for the page ranges
    compress the pages
    submit the compressed extents
      lock extent
        allocate the extent
        insert the pinned extent
        allocate the ordered extent
        clear DELALLOC
      unlock extent
      unlock pages

As you can see there's some variations above, but in essence the extent lock
protects

- Calling into the allocator.
- The em_tree modifications (pinned extent).
- Allocating and attaching the ordered extent.
- Clearing the various bits on the extent_io_tree.
- Looking up the file extent items on disk in the NOCOW case.

We don't actually need to protect the allocator when we're allocating, that has
it's own locking, we're not gaining anything from the lock being held there.

We also don't need to protect looking up the file extent items in the NOCOW
case, we are protected by the page lock here.  There are 3 cases we would need
to be worried about here

- Prealloc.  This locks the inode and calls btrfs_wait_ordered_range() before
  doing the preallocation, so there will be no dirty pages in this range before
  it begins the preallocation.
- Zero range.  Same as above.
- O_DIRECT.  We invalidate the page range before we start the write, so again
  we're protected here.

This allows us to reduce the scope of the extent lock to the 3 things that
really matter

- Protecting the em tree modifications.  This makes sense, this is directly
  related to the inode range.
- Protecting the extent_io_tree modifications.  Again this is clear.
- Allocating and attaching the ordered extent.  Also clear.

With this in mind we can push the extent locking down into the functions that do
these operations, and drastically simplify the locking that we're doing here.

I've run this through several runs of the CI to validate that this doesn't break
anything.  Nothing has failed yet, but it is a rather scary looking change, so a
sharp review is absolutely necessary, and having a decent soak time.  I would
like to get this merged ASAP so we can start pounding on it and make sure it's
solid before I attempt other locking related changes.  Thanks,

Josef
        

Josef Bacik (17):
  btrfs: handle errors in btrfs_reloc_clone_csums properly
  btrfs: push all inline logic into cow_file_range
  btrfs: unlock all the pages with successful inline extent creation
  btrfs: move extent bit and page cleanup into cow_file_range_inline
  btrfs: lock extent when doing inline extent in compression
  btrfs: push the extent lock into btrfs_run_delalloc_range
  btrfs: push extent lock into run_delalloc_nocow
  btrfs: adjust while loop condition in run_delalloc_nocow
  btrfs: push extent lock down in run_delalloc_nocow
  btrfs: remove unlock_extent from run_delalloc_compressed
  btrfs: push extent lock into run_delalloc_cow
  btrfs: push extent lock into cow_file_range
  btrfs: push lock_extent into cow_file_range_inline
  btrfs: move can_cow_file_range_inline() outside of the extent lock
  btrfs: push lock_extent down in cow_file_range()
  btrfs: push extent lock down in submit_one_async_extent
  btrfs: add a cached state to extent_clear_unlock_delalloc

 fs/btrfs/extent_io.c    |   8 +-
 fs/btrfs/extent_io.h    |   2 +
 fs/btrfs/inode.c        | 279 +++++++++++++++++++++++-----------------
 fs/btrfs/ordered-data.c |   6 +
 fs/btrfs/ordered-data.h |   1 +
 fs/btrfs/relocation.c   |   4 +-
 6 files changed, 177 insertions(+), 123 deletions(-)

-- 
2.43.0


^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2024-04-29 14:45 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-17 14:35 [PATCH 00/17] btrfs: restrain lock extent usage during writeback Josef Bacik
2024-04-17 14:35 ` [PATCH 01/17] btrfs: handle errors in btrfs_reloc_clone_csums properly Josef Bacik
2024-04-17 16:01   ` Johannes Thumshirn
2024-04-29 14:38   ` David Sterba
2024-04-17 14:35 ` [PATCH 02/17] btrfs: push all inline logic into cow_file_range Josef Bacik
2024-04-24 17:23   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 03/17] btrfs: unlock all the pages with successful inline extent creation Josef Bacik
2024-04-17 16:14   ` Johannes Thumshirn
2024-04-17 14:35 ` [PATCH 04/17] btrfs: move extent bit and page cleanup into cow_file_range_inline Josef Bacik
2024-04-17 16:24   ` Johannes Thumshirn
2024-04-17 14:35 ` [PATCH 05/17] btrfs: lock extent when doing inline extent in compression Josef Bacik
2024-04-17 16:29   ` Johannes Thumshirn
2024-04-19 18:52     ` Josef Bacik
2024-04-17 14:35 ` [PATCH 06/17] btrfs: push the extent lock into btrfs_run_delalloc_range Josef Bacik
2024-04-24 17:26   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 07/17] btrfs: push extent lock into run_delalloc_nocow Josef Bacik
2024-04-23 11:33   ` Goldwyn Rodrigues
2024-04-23 16:49     ` Josef Bacik
2024-04-24 12:28       ` David Sterba
2024-04-24 17:53     ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 08/17] btrfs: adjust while loop condition in run_delalloc_nocow Josef Bacik
2024-04-18 14:05   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 09/17] btrfs: push extent lock down " Josef Bacik
2024-04-24 17:41   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 10/17] btrfs: remove unlock_extent from run_delalloc_compressed Josef Bacik
2024-04-24 17:43   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 11/17] btrfs: push extent lock into run_delalloc_cow Josef Bacik
2024-04-24 17:45   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 12/17] btrfs: push extent lock into cow_file_range Josef Bacik
2024-04-24 17:46   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 13/17] btrfs: push lock_extent into cow_file_range_inline Josef Bacik
2024-04-24 17:48   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 14/17] btrfs: move can_cow_file_range_inline() outside of the extent lock Josef Bacik
2024-04-23 11:38   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 15/17] btrfs: push lock_extent down in cow_file_range() Josef Bacik
2024-04-24 17:49   ` Goldwyn Rodrigues
2024-04-17 14:36 ` [PATCH 16/17] btrfs: push extent lock down in submit_one_async_extent Josef Bacik
2024-04-23 11:39   ` Goldwyn Rodrigues
2024-04-17 14:36 ` [PATCH 17/17] btrfs: add a cached state to extent_clear_unlock_delalloc Josef Bacik
2024-04-23 11:42   ` Goldwyn Rodrigues
2024-04-24 17:21   ` Goldwyn Rodrigues
2024-04-18  5:54 ` [PATCH 00/17] btrfs: restrain lock extent usage during writeback Christoph Hellwig
2024-04-18 13:45   ` Goldwyn Rodrigues
2024-04-18 14:47     ` Christoph Hellwig
2024-04-19 18:54       ` Josef Bacik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).