[PATCH] btrfs: Reduce scope of delayed_rsv->lock in may_commit_trans

[PATCH] btrfs: Reduce scope of delayed_rsv->lock in may_commit_trans

[Nikolay Borisov]

After commit ('btrfs: change how we decide to commit transactions during
flushing') there is no need to hold the delayed_rsv during the
percpu_counter_compare call since we get the byte's snapshot earlier. So hold
the lock only while reading delayed_rsv

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---

This is based on David's misc-4.15 branch 

 fs/btrfs/extent-tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 673ac4e01dd0..11b7d613140b 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4952,12 +4952,12 @@ static int may_commit_transaction(struct btrfs_fs_info *fs_info,
 		bytes = 0;
 	else
 		bytes -= delayed_rsv->size;
+	spin_unlock(&delayed_rsv->lock);
+
 	if (percpu_counter_compare(&space_info->total_bytes_pinned,
 				   bytes) < 0) {
-		spin_unlock(&delayed_rsv->lock);
 		return -ENOSPC;
 	}
-	spin_unlock(&delayed_rsv->lock);
 
 commit:
 	trans = btrfs_join_transaction(fs_info->extent_root);
-- 
2.7.4

Re: [PATCH] btrfs: Reduce scope of delayed_rsv->lock in may_commit_trans

[David Sterba]

On Tue, Nov 07, 2017 at 11:22:54AM +0200, Nikolay Borisov wrote:
> After commit ('btrfs: change how we decide to commit transactions during

996478ca9c460886ac1

> flushing') there is no need to hold the delayed_rsv during the
> percpu_counter_compare call since we get the byte's snapshot earlier. So hold
> the lock only while reading delayed_rsv
> 
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>

Reviewed-by: David Sterba <dsterba@suse.com>

Re: [PATCH] btrfs: Reduce scope of delayed_rsv->lock in may_commit_trans

[Nikolay Borisov]

On  7.11.2017 22:18, David Sterba wrote:
> On Tue, Nov 07, 2017 at 11:22:54AM +0200, Nikolay Borisov wrote:
>> After commit ('btrfs: change how we decide to commit transactions during
> 
> 996478ca9c460886ac1

That commit is still not pulled by linus so is this id stable?
> 
>> flushing') there is no need to hold the delayed_rsv during the
>> percpu_counter_compare call since we get the byte's snapshot earlier. So hold
>> the lock only while reading delayed_rsv
>>
>> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> 
> Reviewed-by: David Sterba <dsterba@suse.com>
> 

Re: [PATCH] btrfs: Reduce scope of delayed_rsv->lock in may_commit_trans

[David Sterba]

On Tue, Nov 07, 2017 at 10:42:26PM +0200, Nikolay Borisov wrote:
> 
> 
> On  7.11.2017 22:18, David Sterba wrote:
> > On Tue, Nov 07, 2017 at 11:22:54AM +0200, Nikolay Borisov wrote:
> >> After commit ('btrfs: change how we decide to commit transactions during
> > 
> > 996478ca9c460886ac1
> 
> That commit is still not pulled by linus so is this id stable?

Oh right, it's in the pending pull request branch. I don't expect any
changes so the id should be stable, but will keep it in mind anyway.