From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Alexander Gordeev <agordeev@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] blk-mq: Cleanup blk_mq_tag_busy() and blk_mq_tag_idle()
Date: Thu, 4 Sep 2014 20:58:10 -0500 [thread overview]
Message-ID: <20140904205810.3daf3a87@as> (raw)
In-Reply-To: <5409122A.7020703@kernel.dk>
On Thu, 04 Sep 2014 19:30:18 -0600
Jens Axboe <axboe@kernel.dk> wrote:
> On 09/04/2014 07:26 PM, Chuck Ebbert wrote:
> > On Wed, 03 Sep 2014 14:35:29 -0600
> > Jens Axboe <axboe@kernel.dk> wrote:
> >
> >> On 09/03/2014 02:33 PM, Alexander Gordeev wrote:
> > <snip>
> >>> diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
> >>> index 6206ed1..795ec3f 100644
> >>> --- a/block/blk-mq-tag.h
> >>> +++ b/block/blk-mq-tag.h
> >>> @@ -66,23 +66,22 @@ enum {
> >>> BLK_MQ_TAG_MAX = BLK_MQ_TAG_FAIL - 1,
> >>> };
> >>>
> >>> -extern bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
> >>> +extern void __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
> >>> extern void __blk_mq_tag_idle(struct blk_mq_hw_ctx *);
> >>>
> >>> static inline bool blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> >>> {
> >>> - if (!(hctx->flags & BLK_MQ_F_TAG_SHARED))
> >>> - return false;
> >>> -
> >>> - return __blk_mq_tag_busy(hctx);
> >>> + if (hctx->flags & BLK_MQ_F_TAG_SHARED) {
> >>> + __blk_mq_tag_busy(hctx);
> >>> + return true;
> >>> + }
> >>> + return false;
> >>> }
> >>
> >> The normal/fast path here is the flag NOT being set, which is why
> >> it was coded that way to put the fast path inline.
> >>
> >>>
> >>> static inline void blk_mq_tag_idle(struct blk_mq_hw_ctx *hctx)
> >>> {
> >>> - if (!(hctx->flags & BLK_MQ_F_TAG_SHARED))
> >>> - return;
> >>> -
> >>> - __blk_mq_tag_idle(hctx);
> >>> + if (hctx->flags & BLK_MQ_F_TAG_SHARED)
> >>> + __blk_mq_tag_idle(hctx);
> >>> }
> >>
> >> Ditto
> >
> > Shouldn't it just add unlikely() then? That way it's obvious what
> > the common case is, instead of relying on convoluted code.
>
> It's a common construct. Besides, if you find a flag-not-set check
> convoluted, then I hope you are not programming anything I use.
> That's a bit of a straw man, imho.
>
Sure, it's a common construct. But there's nothing there to prevent the
optimizer from rearranging things any way it pleases. Nor is there
anything keeping a human from doing the same. ;)
next prev parent reply other threads:[~2014-09-05 1:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 20:33 [PATCH 0/3] blk-mq: Minor tweaks Alexander Gordeev
2014-09-03 20:33 ` [PATCH 1/3] blk-mq: Cleanup blk_mq_tag_busy() and blk_mq_tag_idle() Alexander Gordeev
2014-09-03 20:35 ` Jens Axboe
2014-09-05 1:26 ` Chuck Ebbert
2014-09-05 1:30 ` Jens Axboe
2014-09-05 1:58 ` Chuck Ebbert [this message]
2014-09-03 20:33 ` [PATCH 2/3] blk-mq: Eliminate superfluous check of BLK_MQ_S_TAG_ACTIVE flag Alexander Gordeev
2014-09-03 20:40 ` Jens Axboe
2014-09-03 20:33 ` [PATCH 3/3] blk-mq: Fix formula to calculate fair share of tags Alexander Gordeev
2014-09-03 20:43 ` Jens Axboe
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=20140904205810.3daf3a87@as \
--to=cebbert.lkml@gmail.com \
--cc=agordeev@redhat.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@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.