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);
>
next prev parent 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).