From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933612AbbBQKGo (ORCPT ); Tue, 17 Feb 2015 05:06:44 -0500 Received: from smtp-out4.electric.net ([192.162.216.182]:51879 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933596AbbBQKGm convert rfc822-to-8bit (ORCPT ); Tue, 17 Feb 2015 05:06:42 -0500 From: David Laight To: "'Greg KH'" , Peter Hung CC: "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 Thread-Topic: [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep Thread-Index: AQHQSiCGUW9hTt50akSXk3Af2D7RUZz0m3og Date: Tue, 17 Feb 2015 10:06:07 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CAE4C78@AcuExch.aculab.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> In-Reply-To: <20150216194115.GB9296@kroah.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. david