From: "'Greg KH'" <gregkh@linuxfoundation.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Peter Hung <hpeter@gmail.com>,
"johan@kernel.org" <johan@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tom_tsai@fintek.com.tw" <tom_tsai@fintek.com.tw>,
"peter_hong@fintek.com.tw" <peter_hong@fintek.com.tw>,
Peter Hung <hpeter+linux_kernel@gmail.com>
Subject: Re: [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep
Date: Tue, 17 Feb 2015 06:48:53 -0800 [thread overview]
Message-ID: <20150217144853.GA17138@kroah.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAE4C78@AcuExch.aculab.com>
On Tue, Feb 17, 2015 at 10:06:07AM +0000, David Laight wrote:
> From: Greg KH
> > > + for (i = 0 ; i < urb->actual_length ; i += 2) {
> > > + tty_flag = TTY_NORMAL;
> > > +
> > > + if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
> >
> > Never use unlikely() unless you can prove that it actually matters if
> > you use it. Hint, it's almost impossible to prove, so don't use it, the
> > compiler and processor look-ahead is almost smarter than we are.
>
> That just isn't true.
>
> The compiler cannot know the actual control flow - so cannot correctly
> arrange the code so that the branches are statically predicted
> correctly for the required path (usually the most common path).
>
> There are a lot of places where a few extra clocks for a mispredicted
> branch don't really matter, and even in very hot paths where it does
> matter it can be quite difficult to get the compiler to optimise the
> branches 'correctly' - you can need to add asm comments in order to
> generate non-empty code blocks.
>
> In addition unlikely() is also a note to the human reader.
>
> I did a lot of work adding likely/unlikely to some code in order
> to minimise the 'worst case' code path. I got there, but some
> parts were initially non-intuitive.
Yes, but remember that old patch that Andi did to actually check to see
if unlikely/likely mattered and was placed correctly? Turns out that
90% of the usages were wrong. So humans are horrible at using these
markings, so I will not accept them unless you can _prove_ it matters in
the code.
For a urb callback, that's not an issue at all, the usb callback is so
slow that you will almost never make a difference, sorry.
So again, don't do it in driver code unless you can prove it.
thanks,
greg k-h
next prev parent reply other threads:[~2015-02-17 14:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 7:57 [PATCH V6 00/10] USB: f81232: V6 patches Peter Hung
2015-02-16 7:57 ` [PATCH V6 01/10] USB: f81232: rename private struct member name Peter Hung
2015-02-16 7:57 ` [PATCH V6 02/10] USB: f81232: implement read IIR/MSR with endpoint Peter Hung
2015-02-17 8:30 ` Johan Hovold
2015-02-16 7:57 ` [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep Peter Hung
2015-02-16 19:41 ` Greg KH
2015-02-17 1:41 ` Peter Hung
2015-02-17 10:06 ` David Laight
2015-02-17 14:48 ` 'Greg KH' [this message]
2015-02-16 7:57 ` [PATCH V6 04/10] USB: f81232: implement set_termios Peter Hung
2015-02-17 8:59 ` Johan Hovold
2015-02-16 7:57 ` [PATCH V6 05/10] USB: f81232: implement MCR/MSR function Peter Hung
2015-02-17 9:40 ` Johan Hovold
2015-02-16 7:57 ` [PATCH V6 06/10] USB: f81232: clarify f81232_ioctl and fix Peter Hung
2015-02-16 7:57 ` [PATCH V6 07/10] USB: f81232: fix error in f81232_carrier_raised() Peter Hung
2015-02-17 9:44 ` Johan Hovold
2015-02-16 7:58 ` [PATCH V6 08/10] USB: f81232: fix read MSR strange value Peter Hung
2015-02-17 9:51 ` Johan Hovold
2015-02-24 2:17 ` Peter Hung
2015-02-16 7:58 ` [PATCH V6 09/10] USB: f81232: implement delta change for MSR count Peter Hung
2015-02-16 7:58 ` [PATCH V6 10/10] USB: f81232: modify/add author Peter Hung
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=20150217144853.GA17138@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=David.Laight@ACULAB.COM \
--cc=hpeter+linux_kernel@gmail.com \
--cc=hpeter@gmail.com \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter_hong@fintek.com.tw \
--cc=tom_tsai@fintek.com.tw \
/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).