From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752248AbbBQOs6 (ORCPT ); Tue, 17 Feb 2015 09:48:58 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:60232 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbbBQOs4 (ORCPT ); Tue, 17 Feb 2015 09:48:56 -0500 Date: Tue, 17 Feb 2015 06:48:53 -0800 From: "'Greg KH'" To: David Laight Cc: Peter Hung , "johan@kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tom_tsai@fintek.com.tw" , "peter_hong@fintek.com.tw" , Peter Hung Subject: Re: [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep Message-ID: <20150217144853.GA17138@kroah.com> References: <1424073482-18164-1-git-send-email-hpeter+linux_kernel@gmail.com> <1424073482-18164-4-git-send-email-hpeter+linux_kernel@gmail.com> <20150216194115.GB9296@kroah.com> <063D6719AE5E284EB5DD2968C1650D6D1CAE4C78@AcuExch.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAE4C78@AcuExch.aculab.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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