From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 00/17] btrfs: restrain lock extent usage during writeback
Date: Wed, 17 Apr 2024 10:35:44 -0400 [thread overview]
Message-ID: <cover.1713363472.git.josef@toxicpanda.com> (raw)
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
next reply other threads:[~2024-04-17 14:36 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 14:35 Josef Bacik [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1713363472.git.josef@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).