All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/3] btrfs: switch extent_buffer spinning_writers from atomic to int
Date: Fri, 31 May 2019 12:19:15 +0300	[thread overview]
Message-ID: <41aca846-afb1-9b83-f442-d791eb929c36@suse.com> (raw)
In-Reply-To: <6dfcb89b254ee5016edfa9816fce3487a23b446c.1559233731.git.dsterba@suse.com>



On 30.05.19 г. 19:31 ч., David Sterba wrote:
> The spinning_writers is either 0 or 1 and always updated under the lock,
> so we don't need the atomic_t semantics.
> 
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
>  fs/btrfs/extent_io.c  |  2 +-
>  fs/btrfs/extent_io.h  |  2 +-
>  fs/btrfs/locking.c    | 10 +++++-----
>  fs/btrfs/print-tree.c |  2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 57b6de9df7c4..71ee9e976307 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -4842,7 +4842,7 @@ __alloc_extent_buffer(struct btrfs_fs_info *fs_info, u64 start,
>  	BUG_ON(len > MAX_INLINE_EXTENT_BUFFER_SIZE);
>  
>  #ifdef CONFIG_BTRFS_DEBUG
> -	atomic_set(&eb->spinning_writers, 0);
> +	eb->spinning_writers = 0;
>  	atomic_set(&eb->spinning_readers, 0);
>  	atomic_set(&eb->read_locks, 0);
>  	atomic_set(&eb->write_locks, 0);
> diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
> index 201da61dfc21..5616b96c365d 100644
> --- a/fs/btrfs/extent_io.h
> +++ b/fs/btrfs/extent_io.h
> @@ -187,7 +187,7 @@ struct extent_buffer {
>  	wait_queue_head_t read_lock_wq;
>  	struct page *pages[INLINE_EXTENT_BUFFER_PAGES];
>  #ifdef CONFIG_BTRFS_DEBUG
> -	atomic_t spinning_writers;
> +	int spinning_writers;
>  	atomic_t spinning_readers;
>  	atomic_t read_locks;
>  	atomic_t write_locks;
> diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
> index 5feb01147e19..270667627977 100644
> --- a/fs/btrfs/locking.c
> +++ b/fs/btrfs/locking.c
> @@ -15,19 +15,19 @@
>  #ifdef CONFIG_BTRFS_DEBUG
>  static void btrfs_assert_spinning_writers_get(struct extent_buffer *eb)
>  {
> -	WARN_ON(atomic_read(&eb->spinning_writers));
> -	atomic_inc(&eb->spinning_writers);
> +	WARN_ON(eb->spinning_writers);
> +	eb->spinning_writers++;
>  }
>  
>  static void btrfs_assert_spinning_writers_put(struct extent_buffer *eb)
>  {
> -	WARN_ON(atomic_read(&eb->spinning_writers) != 1);
> -	atomic_dec(&eb->spinning_writers);
> +	WARN_ON(eb->spinning_writers != 1);
> +	eb->spinning_writers--;
>  }
>  
>  static void btrfs_assert_no_spinning_writers(struct extent_buffer *eb)
>  {
> -	WARN_ON(atomic_read(&eb->spinning_writers));
> +	WARN_ON(eb->spinning_writers);
>  }

IMO longterm  it will be good if those debug functions contained
lockdep_assert_held_exclusive/read macros for posterity.

>  
>  static void btrfs_assert_spinning_readers_get(struct extent_buffer *eb)
> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
> index 7cb4f1fbe043..c5cc435ed39a 100644
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> @@ -157,7 +157,7 @@ static void print_eb_refs_lock(struct extent_buffer *eb)
>  		   atomic_read(&eb->read_locks),
>  		   eb->blocking_writers,
>  		   atomic_read(&eb->blocking_readers),
> -		   atomic_read(&eb->spinning_writers),
> +		   eb->spinning_writers,
>  		   atomic_read(&eb->spinning_readers),
>  		   eb->lock_owner, current->pid);
>  #endif
> 

  reply	other threads:[~2019-05-31  9:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 16:30 [PATCH 0/3] Extent buffer lock cleanups David Sterba
2019-05-30 16:31 ` [PATCH 1/3] btrfs: switch extent_buffer blocking_writers from atomic to int David Sterba
2019-05-31  8:29   ` Nikolay Borisov
2019-05-30 16:31 ` [PATCH 2/3] btrfs: switch extent_buffer spinning_writers " David Sterba
2019-05-31  9:19   ` Nikolay Borisov [this message]
2019-05-31 11:28     ` David Sterba
2019-05-30 16:31 ` [PATCH 3/3] btrfs: switch extent_buffer write_locks " David Sterba
2019-05-31  9:20   ` Nikolay Borisov
2019-06-07 13:31 ` [PATCH 0/3] Extent buffer lock cleanups 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=41aca846-afb1-9b83-f442-d791eb929c36@suse.com \
    --to=nborisov@suse.com \
    --cc=dsterba@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.