Re: [PATCH] btrfs: skip the extent map tree lock for inodes without extent maps

From: Filipe Manana

Date: Fri Aug 21 2026 - 07:20:01 EST


On Fri, Aug 21, 2026 at 11:39 AM Breno Leitao <leitao@xxxxxxxxxx> wrote:
>
> The shrinker (find_first_inode_to_shrink()) takes inode->extent_tree.lock in write
> mode on every inode it walks, only to find out whether that inode has
> any extent maps.
>
> Most have none, from what I understand, so, avoid the lock by testing the
> tree with a plain read before taking the lock. tree->root is only
> modified with the tree lock held for write, so the unlocked read is
> a benign race: a false negative just defers the inode to a later scan.
>
> On my tests, find_first_inode_to_shrink() was a bit faster, so, if this
> patch is correct, I think it is worth having to reduce lock contention.

When claiming performance gains in a patch, please always mention what
those gains were....

>
> Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
> ---
> fs/btrfs/extent_map.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index 6ad7b39ae358b..cdcd2b779050d 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -1219,6 +1219,9 @@ static struct btrfs_inode *find_first_inode_to_shrink(struct btrfs_root *root,
>
> tree = &inode->extent_tree;
>
> + if (!READ_ONCE(tree->root.rb_node))

Please use the proper rbtree api to check if a tree is empty:

RB_EMPTY_ROOT(&tree->root)

That's a lot more elegant and hides the use of READ_ONCE().

But really when there are harmless races, I like to see an explicit
data_race() annotation and a comment about why the race is harmless.

Nevertheless, first, I would like to know how much the performance
improvement was...

Thanks.



> + goto next;
> +
> /*
> * We want to be fast so if the lock is busy we don't want to
> * spend time waiting for it (some task is about to do IO for
>
> ---
> base-commit: 6a746cd265aed59107ebdaa9ce039bb832922969
> change-id: 20260820-b4-btrfs-em-shrinker-7382d7f0dd05
>
> Best regards,
> --
> Breno Leitao <leitao@xxxxxxxxxx>
>
>