linux-btrfs.vger.kernel.org archive mirror
 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] btrfs: annotate unlikely branches after V0 extent type removal
Date: Tue, 26 Jun 2018 17:31:40 +0300	[thread overview]
Message-ID: <102d6eae-cae6-1c1a-853c-c8fb41894c50@suse.com> (raw)
In-Reply-To: <20180626142414.12874-1-dsterba@suse.com>



On 26.06.2018 17:24, David Sterba wrote:
> The v0 extent type checks are the right case for the unlikely
> annotations as we don't expect to ever see them, so let's give the
> compiler some hint.
> 
> Signed-off-by: David Sterba <dsterba@suse.com>

The question is how helpful those unlikelies are in the generated code.
Also according to the comment about __cold annotation this already gives
the compiler a hint that any code leading to such a cold function is
already unlikely.

Anyways:

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

> ---
>  fs/btrfs/extent-tree.c | 8 ++++----
>  fs/btrfs/print-tree.c  | 2 +-
>  fs/btrfs/relocation.c  | 8 ++++----
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 8713a1693dfc..d3f7afe3a548 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -1310,7 +1310,7 @@ static noinline int remove_extent_data_ref(struct btrfs_trans_handle *trans,
>  		ref2 = btrfs_item_ptr(leaf, path->slots[0],
>  				      struct btrfs_shared_data_ref);
>  		num_refs = btrfs_shared_data_ref_count(leaf, ref2);
> -	} else if (key.type == BTRFS_EXTENT_REF_V0_KEY) {
> +	} else if (unlikely(key.type == BTRFS_EXTENT_REF_V0_KEY)) {
>  		btrfs_print_v0_err(fs_info);
>  		btrfs_abort_transaction(trans, -EINVAL);
>  		return -EINVAL;
> @@ -1563,7 +1563,7 @@ int lookup_inline_extent_backref(struct btrfs_trans_handle *trans,
>  
>  	leaf = path->nodes[0];
>  	item_size = btrfs_item_size_nr(leaf, path->slots[0]);
> -	if (item_size < sizeof(*ei)) {
> +	if (unlikely(item_size < sizeof(*ei))) {
>  		err = -EINVAL;
>  		btrfs_print_v0_err(fs_info);
>  		btrfs_abort_transaction(trans, err);
> @@ -2269,7 +2269,7 @@ static int run_delayed_extent_op(struct btrfs_trans_handle *trans,
>  	leaf = path->nodes[0];
>  	item_size = btrfs_item_size_nr(leaf, path->slots[0]);
>  
> -	if (item_size < sizeof(*ei)) {
> +	if (unlikely(item_size < sizeof(*ei))) {
>  		err = -EINVAL;
>  		btrfs_print_v0_err(fs_info);
>  		btrfs_abort_transaction(trans, err);
> @@ -6811,7 +6811,7 @@ static int __btrfs_free_extent(struct btrfs_trans_handle *trans,
>  
>  	leaf = path->nodes[0];
>  	item_size = btrfs_item_size_nr(leaf, extent_slot);
> -	if (item_size < sizeof(*ei)) {
> +	if (unlikely(item_size < sizeof(*ei))) {
>  		ret = -EINVAL;
>  		btrfs_print_v0_err(info);
>  		btrfs_abort_transaction(trans, ret);
> diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
> index 772560eecfa6..0dd44d161935 100644
> --- a/fs/btrfs/print-tree.c
> +++ b/fs/btrfs/print-tree.c
> @@ -52,7 +52,7 @@ static void print_extent_item(struct extent_buffer *eb, int slot, int type)
>  	u64 offset;
>  	int ref_index = 0;
>  
> -	if (item_size < sizeof(*ei)) {
> +	if (unlikely(item_size < sizeof(*ei))) {
>  		btrfs_print_v0_err(eb->fs_info);
>  		btrfs_handle_fs_error(eb->fs_info, -EINVAL, NULL);
>  	}
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index a8dddefaae99..381bd3c24249 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -832,7 +832,7 @@ struct backref_node *build_backref_tree(struct reloc_control *rc,
>  			goto next;
>  		} else if (key.type != BTRFS_TREE_BLOCK_REF_KEY) {
>  			goto next;
> -		} else if (key.type == BTRFS_EXTENT_REF_V0_KEY) {
> +		} else if (unlikely(key.type == BTRFS_EXTENT_REF_V0_KEY)) {
>  			err = -EINVAL;
>  			btrfs_print_v0_err(rc->extent_root->fs_info);
>  			btrfs_handle_fs_error(rc->extent_root->fs_info, err,
> @@ -3325,7 +3325,7 @@ static int add_tree_block(struct reloc_control *rc,
>  			level = (int)extent_key->offset;
>  		}
>  		generation = btrfs_extent_generation(eb, ei);
> -	} else if (item_size == sizeof(struct btrfs_extent_item_v0)) {
> +	} else if (unlikely(item_size == sizeof(struct btrfs_extent_item_v0))) {
>  		btrfs_print_v0_err(eb->fs_info);
>  		btrfs_handle_fs_error(eb->fs_info, -EINVAL, NULL);
>  		return -EINVAL;
> @@ -3742,7 +3742,7 @@ int add_data_references(struct reloc_control *rc,
>  					      struct btrfs_extent_data_ref);
>  			ret = find_data_references(rc, extent_key,
>  						   eb, dref, blocks);
> -		} else if (key.type == BTRFS_EXTENT_REF_V0_KEY) {
> +		} else if (unlikely(key.type == BTRFS_EXTENT_REF_V0_KEY)) {
>  			btrfs_print_v0_err(eb->fs_info);
>  			btrfs_handle_fs_error(eb->fs_info, -EINVAL, NULL);
>  			ret = -EINVAL;
> @@ -3984,7 +3984,7 @@ static noinline_for_stack int relocate_block_group(struct reloc_control *rc)
>  			flags = btrfs_extent_flags(path->nodes[0], ei);
>  			ret = check_extent_flags(flags);
>  			BUG_ON(ret);
> -		} else if (item_size == sizeof(struct btrfs_extent_item_v0)) {
> +		} else if (unlikely(item_size == sizeof(struct btrfs_extent_item_v0))) {
>  			err = -EINVAL;
>  			btrfs_print_v0_err(trans->fs_info);
>  			btrfs_abort_transaction(trans, err);
> 

  reply	other threads:[~2018-06-26 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25  8:24 [PATCH 0/2] Remove v0 extent support Nikolay Borisov
2018-06-25  8:24 ` [PATCH 1/2] btrfs: Remove V0 " Nikolay Borisov
2018-06-25  8:24 ` [PATCH 2/2] btrfs: Add graceful handling of V0 extents Nikolay Borisov
2018-06-25 15:21   ` David Sterba
2018-06-26 13:57     ` [PATCH v2] " Nikolay Borisov
2018-06-26 14:17       ` David Sterba
2018-06-27 13:12         ` Noah Massey
2018-06-27 13:21           ` David Sterba
2018-06-26 14:24       ` [PATCH] btrfs: annotate unlikely branches after V0 extent type removal David Sterba
2018-06-26 14:31         ` Nikolay Borisov [this message]
2018-06-26 14:43           ` David Sterba
2018-06-26 16:05       ` [PATCH v2] btrfs: Add graceful handling of V0 extents kbuild test robot
2018-06-26 17:12         ` David Sterba
2018-06-26 17:44       ` kbuild test robot

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=102d6eae-cae6-1c1a-853c-c8fb41894c50@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 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).