From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754713AbZBIKnX (ORCPT ); Mon, 9 Feb 2009 05:43:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753121AbZBIKnN (ORCPT ); Mon, 9 Feb 2009 05:43:13 -0500 Received: from h155.mvista.com ([63.81.120.155]:7868 "EHLO imap.sh.mvista.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752917AbZBIKnM (ORCPT ); Mon, 9 Feb 2009 05:43:12 -0500 Message-ID: <499008B7.3020404@ru.mvista.com> Date: Mon, 09 Feb 2009 13:43:03 +0300 From: Sergei Shtylyov User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jeff Garzik Cc: Mikael Pettersson , Hugh Dickins , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk, rjw@sisk.pl Subject: Re: [PATCH] libata-sff: fix 32-bit PIO regression References: <200902082253.07438.sshtylyov@ru.mvista.com> <498F5A25.90707@ru.mvista.com> <18831.28471.454273.451912@harpo.it.uu.se> <498F72C8.8020204@ru.mvista.com> <498F767B.9060701@pobox.com> In-Reply-To: <498F767B.9060701@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello. Jeff Garzik wrote: >> Do you really think that the transfers having lengths non-divisible >> by 4 make any *significant* percentage even on the ATAPI devices? I >> think it's you who is really wrong. > > The answer depends on workload. Though rare, workloads do exist that > involve a lot of oddball querying via weird, vendor-specific > SCSI[-ish] commands. Can you give an example of a *continous* querying with the data transferring commands? Hm, it just occured to me that the typical ATAPI command packet is 12 bytes long. > Moreover, the likelihood and cost of a branch mispredict are both low > in this case, IMO. > > Or a more human version of the rule: if you have to have a long email > thread about unlikely() placement, it is best just to avoid using > unlikely() in that case at all. Branch prediction units in modern > CPUs are damned good anyways, and there is always the likelihood that > a human-placed unlikely() becomes wrong in the future. There are still CPUs without the branch prediction, you know -- Linux runs not only on x86. > Plus the code is more readable without unlikely(), IMO. I tend to disagree. However, the packet command transfer is not unlikely at all, so I'll remove that unlikely() in the respun patch. > Jeff MBR, Sergei