linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: dsterba@suse.cz, Josef Bacik <josef@toxicpanda.com>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH 1/6] btrfs: add btrfs_delete_ref_head helper
Date: Fri, 23 Nov 2018 15:50:45 +0200	[thread overview]
Message-ID: <1b29b7a7-ab71-4c33-dbdd-077fd92342f4@suse.com> (raw)
In-Reply-To: <20181123134525.GC2842@twin.jikos.cz>



On 23.11.18 г. 15:45 ч., David Sterba wrote:
> On Thu, Nov 22, 2018 at 11:42:28AM +0200, Nikolay Borisov wrote:
>>
>>
>> On 22.11.18 г. 11:12 ч., Nikolay Borisov wrote:
>>>
>>>
>>> On 21.11.18 г. 20:59 ч., Josef Bacik wrote:
>>>> From: Josef Bacik <jbacik@fb.com>
>>>>
>>>> We do this dance in cleanup_ref_head and check_ref_cleanup, unify it
>>>> into a helper and cleanup the calling functions.
>>>>
>>>> Signed-off-by: Josef Bacik <jbacik@fb.com>
>>>> Reviewed-by: Omar Sandoval <osandov@fb.com>
>>>> ---
>>>>  fs/btrfs/delayed-ref.c | 14 ++++++++++++++
>>>>  fs/btrfs/delayed-ref.h |  3 ++-
>>>>  fs/btrfs/extent-tree.c | 22 +++-------------------
>>>>  3 files changed, 19 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
>>>> index 9301b3ad9217..b3e4c9fcb664 100644
>>>> --- a/fs/btrfs/delayed-ref.c
>>>> +++ b/fs/btrfs/delayed-ref.c
>>>> @@ -400,6 +400,20 @@ struct btrfs_delayed_ref_head *btrfs_select_ref_head(
>>>>  	return head;
>>>>  }
>>>>  
>>>> +void btrfs_delete_ref_head(struct btrfs_delayed_ref_root *delayed_refs,
>>>> +			   struct btrfs_delayed_ref_head *head)
>>>> +{
>>>> +	lockdep_assert_held(&delayed_refs->lock);
>>>> +	lockdep_assert_held(&head->lock);
>>>> +
>>>> +	rb_erase_cached(&head->href_node, &delayed_refs->href_root);
>>>> +	RB_CLEAR_NODE(&head->href_node);
>>>> +	atomic_dec(&delayed_refs->num_entries);
>>>> +	delayed_refs->num_heads--;
>>>> +	if (head->processing == 0)
>>>> +		delayed_refs->num_heads_ready--;
>>>
>>> num_heads_ready will never execute in cleanup_ref_head, since
>>> processing == 0 only when the ref head is unselected. Perhaps those 2
>>> lines shouldn't be in this function? I find it a bit confusing that if
>>> processing is 0 we decrement num_heads_ready in check_ref_cleanup, but
>>> in unselect_delayed_ref_head we set it to 0 and increment it.
>>>
>>>> +}
>>>> +
>>>>  /*
>>>>   * Helper to insert the ref_node to the tail or merge with tail.
>>>>   *
>>>> diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs/delayed-ref.h
>>>> index 8e20c5cb5404..d2af974f68a1 100644
>>>> --- a/fs/btrfs/delayed-ref.h
>>>> +++ b/fs/btrfs/delayed-ref.h
>>>> @@ -261,7 +261,8 @@ static inline void btrfs_delayed_ref_unlock(struct btrfs_delayed_ref_head *head)
>>>>  {
>>>>  	mutex_unlock(&head->mutex);
>>>>  }
>>>> -
>>>> +void btrfs_delete_ref_head(struct btrfs_delayed_ref_root *delayed_refs,
>>>> +			   struct btrfs_delayed_ref_head *head);
>>>>  
>>>>  struct btrfs_delayed_ref_head *btrfs_select_ref_head(
>>>>  		struct btrfs_delayed_ref_root *delayed_refs);
>>>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
>>>> index d242a1174e50..c36b3a42f2bb 100644
>>>> --- a/fs/btrfs/extent-tree.c
>>>> +++ b/fs/btrfs/extent-tree.c
>>>> @@ -2474,12 +2474,9 @@ static int cleanup_ref_head(struct btrfs_trans_handle *trans,
>>>>  		spin_unlock(&delayed_refs->lock);
>>>>  		return 1;
>>>>  	}
>>>> -	delayed_refs->num_heads--;
>>>> -	rb_erase_cached(&head->href_node, &delayed_refs->href_root);
>>>> -	RB_CLEAR_NODE(&head->href_node);
>>>> +	btrfs_delete_ref_head(delayed_refs, head);
>>>>  	spin_unlock(&head->lock);
>>>>  	spin_unlock(&delayed_refs->lock);
>>>> -	atomic_dec(&delayed_refs->num_entries);
>>>>  
>>>>  	trace_run_delayed_ref_head(fs_info, head, 0);
>>>>  
>>>> @@ -6984,22 +6981,9 @@ static noinline int check_ref_cleanup(struct btrfs_trans_handle *trans,
>>>>  	if (!mutex_trylock(&head->mutex))
>>>>  		goto out;
>>>>  
>>>> -	/*
>>>> -	 * at this point we have a head with no other entries.  Go
>>>> -	 * ahead and process it.
>>>> -	 */
>>>> -	rb_erase_cached(&head->href_node, &delayed_refs->href_root);
>>>> -	RB_CLEAR_NODE(&head->href_node);
>>>> -	atomic_dec(&delayed_refs->num_entries);
>>>> -
>>>> -	/*
>>>> -	 * we don't take a ref on the node because we're removing it from the
>>>> -	 * tree, so we just steal the ref the tree was holding.
>>>> -	 */
>>>> -	delayed_refs->num_heads--;
>>>> -	if (head->processing == 0)
>>>> -		delayed_refs->num_heads_ready--;
>>>> +	btrfs_delete_ref_head(delayed_refs, head);
>>>>  	head->processing = 0;
>>
>> On a closer inspection I think here we can do:
>>
>> ASSERT(head->processing == 0) because at that point we've taken the
>> head->lock spinlock which is held during ordinary delayed refs
>> processing (in __btrfs_run_delayed_refs) when the head is selected (and
>> processing is 1). So head->processing == 0 here I think is a hard
>> invariant of the code. The decrement here should pair with the increment
>> when the head was initially added to the tree.
>>
>> In cleanup_ref_head we don't need to ever worry about num_heads_ready
>> since it has already been decremented by btrfs_select_ref_head.
>>
>> As a matter fact this counter is not used anywhere so we might as well
>> just remove it.
> 
> The logic does not use it, there's only a WARN_ON in
> btrfs_select_ref_head, that's more like a debugging or assertion that
> everything is fine. So the question is whether to keep it as a
> consistency check (and add comments) or remove it and simplify the code.

IMO it should go. A later patch pretty much tracks what this number used
to to track - btrfs: only track ref_heads in delayed_ref_updates.

Even for consistency I don't see much value brought by num_heads_ready.

> 

  reply	other threads:[~2018-11-23 13:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 18:59 [PATCH 0/6] Delayed refs rsv Josef Bacik
2018-11-21 18:59 ` [PATCH 1/6] btrfs: add btrfs_delete_ref_head helper Josef Bacik
2018-11-22  9:12   ` Nikolay Borisov
2018-11-22  9:42     ` Nikolay Borisov
2018-11-23 13:45       ` David Sterba
2018-11-23 13:50         ` Nikolay Borisov [this message]
2018-11-21 18:59 ` [PATCH 2/6] btrfs: add cleanup_ref_head_accounting helper Josef Bacik
2018-11-22  1:06   ` Qu Wenruo
2018-11-23 13:51     ` David Sterba
2018-11-21 18:59 ` [PATCH 3/6] btrfs: cleanup extent_op handling Josef Bacik
2018-11-22  8:56   ` Lu Fengqi
2018-11-22 10:09   ` Nikolay Borisov
2018-11-27 15:39     ` Josef Bacik
2018-11-23 15:05   ` David Sterba
2018-11-21 18:59 ` [PATCH 4/6] btrfs: only track ref_heads in delayed_ref_updates Josef Bacik
2018-11-22 10:19   ` Nikolay Borisov
2018-11-21 18:59 ` [PATCH 5/6] btrfs: introduce delayed_refs_rsv Josef Bacik
2018-11-26  9:14   ` Nikolay Borisov
2018-11-27 15:38     ` David Sterba
2018-11-27 19:11     ` Josef Bacik
2018-11-21 18:59 ` [PATCH 6/6] btrfs: fix truncate throttling Josef Bacik
2018-11-26  9:44   ` Nikolay Borisov
2018-11-23 15:55 ` [PATCH 0/6] Delayed refs rsv David Sterba

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=1b29b7a7-ab71-4c33-dbdd-077fd92342f4@suse.com \
    --to=nborisov@suse.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fb.com \
    --cc=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 NNTP newsgroup(s).