Re: [PATCH v2] btrfs: reduce ordered_extent_lock section at btrfs_split_ordered_extent()

[David Sterba <dsterba@suse.cz>]

On Wed, May 29, 2024 at 12:51:13PM +0100, Filipe Manana wrote:
> On Tue, May 28, 2024 at 11:22 PM David Sterba <dsterba@suse.cz> wrote:
> >
> > On Tue, May 14, 2024 at 06:54:18PM +0100, fdmanana@kernel.org wrote:
> > > From: Filipe Manana <fdmanana@suse.com>
> > >
> > > There's no need to hold the root's ordered_extent_lock for so long at
> > > btrfs_split_ordered_extent(). We don't need to hold it in order to modify
> > > the inode's rb tree of ordered extents, to modify the trimmed ordered
> > > extent and move checksums between the trimmed and the new ordered extent.
> > > That's only increasing contention of the root's ordered_extent_lock for
> > > other writes that are starting or completing.
> > >
> > > So lock the root's ordered_extent_lock only before we add the new ordered
> > > extent to the root's ordered list and increment the root's counter for the
> > > number of ordered extents.
> > >
> > > Signed-off-by: Filipe Manana <fdmanana@suse.com>
> >
> > Reviewed-by: David Sterba <dsterba@suse.com>
> 
> This needs to be dropped for now as there are some problems there.
> I'll address those in a patch set.

I had the patch in my testing branch and did not notice anything that
would point to this patch but I did not do any target testing.

Moving the IRQ context was fixed in v2, the pattern of independent
ranges of ordered_tree_lock and ordered_extent_lock changes the
semantics, another case is in insert_ordered_extent() but it could be
fine there.