Message ID | Y+I7/QpQYjBXutLf@ubun2204.myguest.virtualbox.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2805427wrn; Tue, 7 Feb 2023 03:57:27 -0800 (PST) X-Google-Smtp-Source: AK7set/f9EgY26T+CoGDS5NtIm30YeTQNRDf6mMK8s8Ax0uEDvLqnjpPcy64jacihc38LMe4Rcxp X-Received: by 2002:a50:cc9d:0:b0:4aa:cb90:7c2 with SMTP id q29-20020a50cc9d000000b004aacb9007c2mr1996914edi.10.1675771046882; Tue, 07 Feb 2023 03:57:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675771046; cv=none; d=google.com; s=arc-20160816; b=zoh27VUdskkY+rz2RCS8oGWsGIesNlInxgO04t8KGkhTD9ObXAOMwM4XmoJWcUQwud CJ3apKgktqFwetKPmgxUuEi98v6C+q5362+GHb74EQFDOdocSsh4FtFoUHRNNn+9F4H8 h1L6xBkyJyMqF67B3cWQ3c0yLFX+bmYIdQEU+Zye2WEPwrHCZcpro5qvlKqSL9XwHWry 60yAVibvPzyUP2x6Vu3wf9GW9ybmmkUrECYDO65duv7VHWsLtZOIctmlSf9IBqROMYVk TM4dyPq2GCmtoadI3g53UyFRrnqQ2jJlodZ02BQjJzbYEsLhI/Vq9TYaT0Hg8y2F4Lxa wPAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=7s9cTezN7LVViZlu5DIggA3MitOfxbjWWqsFmPM5gbI=; b=lylARGJah0VMgJb2+r4qAh/L4F3PjFDUtkccgn2peuZ+e22q+OP8JY9X9hUWimtLcL IOIsBtzf5UxP0m+w0+vYG9fkKyhJfedrYWGcn4f+/FJ3LpdAY6lOxOE1Q2y1oNURvzON OXNK1Ti6cVFhMabNWcLu9njEBlaM7R0BvK1cJroDBuj69MhXddrfdyPxRYkqWk+UUH0K SOZhsyh421oeoEclKFbXdwCdqTfKkTdyTdywmMJxRro5k/wunU7Gyj1c/3DaPQI9H8KG 4ujCPMXhbB/MxzcLlp3RXLybYNSHbZ/TOrHM+i+Q5b4wekGR9i8uUQkcdc7utE/yzM6C QKeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=DvqUJEJO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u15-20020aa7d0cf000000b004a20d8b233esi2020225edo.317.2023.02.07.03.57.03; Tue, 07 Feb 2023 03:57:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=DvqUJEJO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230451AbjBGLyz (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Tue, 7 Feb 2023 06:54:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjBGLyy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Feb 2023 06:54:54 -0500 Received: from msg-4.mailo.com (msg-4.mailo.com [213.182.54.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC7B8F752; Tue, 7 Feb 2023 03:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1675770883; bh=SaUu9T4vaIZciJlVkGRy87wxHmCtXAbwvw+39ODNwlw=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:MIME-Version: Content-Type; b=DvqUJEJOto8u3e9OTH/T0jX42fvj5sQj1LYOOrELo80jRoKrnau8n8yQBRHgwcw6S lUkj/SEUiLjz/GQRy062Mg/do0J9S2nnV6lYhxT19+OamkRTtyRD8ACY3pGKpGpEHb yX+XP5qJU9cJla3KGnY4jo/cr2ML/jCQfKg/0NoQ= Received: by b-4.in.mailobj.net [192.168.90.14] with ESMTP via ip-206.mailobj.net [213.182.55.206] Tue, 7 Feb 2023 12:54:43 +0100 (CET) X-EA-Auth: bTmKoI02WghlHFGMmY+O2C5h3+AW3/JQnLXwyq7DYGmBt211b5gzWTn9UghYDJ/q155Yr1KW3Tl6rlJMjCKqKxCBUjpXR6SS Date: Tue, 7 Feb 2023 17:24:37 +0530 From: Deepak R Varma <drv@mailo.com> To: Michael Reed <mdr@sgi.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Saurabh Singh Sengar <ssengar@microsoft.com>, Praveen Kumar <kumarpraveen@linux.microsoft.com>, Deepak R Varma <drv@mailo.com> Subject: [PATCH] scsi: qla1280: Replace arithmetic addition by bitwise OR Message-ID: <Y+I7/QpQYjBXutLf@ubun2204.myguest.virtualbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757173300935587395?= X-GMAIL-MSGID: =?utf-8?q?1757173300935587395?= |
Series |
scsi: qla1280: Replace arithmetic addition by bitwise OR
|
|
Commit Message
Deepak R Varma
Feb. 7, 2023, 11:54 a.m. UTC
When adding two bit-field mask values, an OR operation offers higher
performance over an arithmetic operation. So, convert such addition to
an OR based expression.
Issue identified using orplus.cocci semantic patch script.
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
drivers/scsi/qla1280.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 2/7/23 03:54, Deepak R Varma wrote: > When adding two bit-field mask values, an OR operation offers higher > performance over an arithmetic operation. So, convert such addition to > an OR based expression. Where is the evidence that supports this claim? On the following page I read that there is no performance difference when using a modern CPU: https://cs.stackexchange.com/questions/75811/why-is-addition-as-fast-as-bit-wise-operations-in-modern-processors > Issue identified using orplus.cocci semantic patch script. Where is that script located? Can it be deleted such that submission of patches similar to this patch stops? Thanks, Bart.
On Sat, Feb 11, 2023 at 03:25:03PM -0800, Bart Van Assche wrote: > On 2/7/23 03:54, Deepak R Varma wrote: > > When adding two bit-field mask values, an OR operation offers higher > > performance over an arithmetic operation. So, convert such addition to > > an OR based expression. > > Where is the evidence that supports this claim? On the following page I read > that there is no performance difference when using a modern CPU: https://cs.stackexchange.com/questions/75811/why-is-addition-as-fast-as-bit-wise-operations-in-modern-processors > Hello Bart, You are correct. Modern CPU designs have improved addition and the performance is at par with the bitwise operation. The document I had read earlier mentioned a performance improvement for old CPUs and microprocessors, which today is not the case. Thank you for sharing the link. > > Issue identified using orplus.cocci semantic patch script. > > Where is that script located? Can it be deleted such that submission of > patches similar to this patch stops? I have added Julia to this email to understand how to best use this semantic patch. I already discussed with her on improving the Semantic patch such that it doesn't suggest making change when constants are involved. Thank you, ./drv > > Thanks, > > Bart.
On Sun, 12 Feb 2023, Deepak R Varma wrote: > On Sat, Feb 11, 2023 at 03:25:03PM -0800, Bart Van Assche wrote: > > On 2/7/23 03:54, Deepak R Varma wrote: > > > When adding two bit-field mask values, an OR operation offers higher > > > performance over an arithmetic operation. So, convert such addition to > > > an OR based expression. > > > > Where is the evidence that supports this claim? On the following page I read > > that there is no performance difference when using a modern CPU: https://cs.stackexchange.com/questions/75811/why-is-addition-as-fast-as-bit-wise-operations-in-modern-processors > > > > Hello Bart, > You are correct. Modern CPU designs have improved addition and the performance > is at par with the bitwise operation. The document I had read earlier mentioned > a performance improvement for old CPUs and microprocessors, which today is not > the case. Thank you for sharing the link. > > > > Issue identified using orplus.cocci semantic patch script. > > > > Where is that script located? Can it be deleted such that submission of > > patches similar to this patch stops? > > I have added Julia to this email to understand how to best use this semantic > patch. I already discussed with her on improving the Semantic patch such that it > doesn't suggest making change when constants are involved. FWIW, the semantic patch was never motivated by efficiency, but rather with the goal of making the code more understandable. julia
On Sun, Feb 12, 2023 at 04:11:58PM +0100, Julia Lawall wrote: > > > On Sun, 12 Feb 2023, Deepak R Varma wrote: > > > On Sat, Feb 11, 2023 at 03:25:03PM -0800, Bart Van Assche wrote: > > > On 2/7/23 03:54, Deepak R Varma wrote: > > > > When adding two bit-field mask values, an OR operation offers higher > > > > performance over an arithmetic operation. So, convert such addition to > > > > an OR based expression. > > > > > > Where is the evidence that supports this claim? On the following page I read > > > that there is no performance difference when using a modern CPU: https://cs.stackexchange.com/questions/75811/why-is-addition-as-fast-as-bit-wise-operations-in-modern-processors > > > > > > > Hello Bart, > > You are correct. Modern CPU designs have improved addition and the performance > > is at par with the bitwise operation. The document I had read earlier mentioned > > a performance improvement for old CPUs and microprocessors, which today is not > > the case. Thank you for sharing the link. > > > > > > Issue identified using orplus.cocci semantic patch script. > > > > > > Where is that script located? Can it be deleted such that submission of > > > patches similar to this patch stops? > > > > I have added Julia to this email to understand how to best use this semantic > > patch. I already discussed with her on improving the Semantic patch such that it > > doesn't suggest making change when constants are involved. > > FWIW, the semantic patch was never motivated by efficiency, but rather > with the goal of making the code more understandable. I think my interpretation of the patch log for [1] was not accurate. The line "Running time is divided by 3 ..." made me believe OR'ing would replace "F+A+R" instructions by a single operation. My bad. [1] https://lore.kernel.org/all/alpine.DEB.2.20.1711130649370.2483@hadrien/ > > julia
On Sun, 12 Feb 2023, Deepak R Varma wrote: > On Sun, Feb 12, 2023 at 04:11:58PM +0100, Julia Lawall wrote: > > > > > > On Sun, 12 Feb 2023, Deepak R Varma wrote: > > > > > On Sat, Feb 11, 2023 at 03:25:03PM -0800, Bart Van Assche wrote: > > > > On 2/7/23 03:54, Deepak R Varma wrote: > > > > > When adding two bit-field mask values, an OR operation offers higher > > > > > performance over an arithmetic operation. So, convert such addition to > > > > > an OR based expression. > > > > > > > > Where is the evidence that supports this claim? On the following page I read > > > > that there is no performance difference when using a modern CPU: https://cs.stackexchange.com/questions/75811/why-is-addition-as-fast-as-bit-wise-operations-in-modern-processors > > > > > > > > > > Hello Bart, > > > You are correct. Modern CPU designs have improved addition and the performance > > > is at par with the bitwise operation. The document I had read earlier mentioned > > > a performance improvement for old CPUs and microprocessors, which today is not > > > the case. Thank you for sharing the link. > > > > > > > > Issue identified using orplus.cocci semantic patch script. > > > > > > > > Where is that script located? Can it be deleted such that submission of > > > > patches similar to this patch stops? > > > > > > I have added Julia to this email to understand how to best use this semantic > > > patch. I already discussed with her on improving the Semantic patch such that it > > > doesn't suggest making change when constants are involved. > > > > FWIW, the semantic patch was never motivated by efficiency, but rather > > with the goal of making the code more understandable. > > I think my interpretation of the patch log for [1] was not accurate. The line > "Running time is divided by 3 ..." made me believe OR'ing would replace "F+A+R" > instructions by a single operation. My bad. Ah, interesting. I have no idea any more the running time of what. julia > > [1] https://lore.kernel.org/all/alpine.DEB.2.20.1711130649370.2483@hadrien/ > > > > > julia > > >
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c index 1e7f4d138e06..d806beb4ad1c 100644 --- a/drivers/scsi/qla1280.c +++ b/drivers/scsi/qla1280.c @@ -3709,7 +3709,7 @@ qla1280_error_entry(struct scsi_qla_host *ha, struct response *pkt, ha->outstanding_cmds[handle] = NULL; /* Bad payload or header */ - if (pkt->entry_status & (BIT_3 + BIT_2)) { + if (pkt->entry_status & (BIT_3 | BIT_2)) { /* Bad payload or header, set error status. */ /* CMD_RESULT(sp->cmd) = CS_BAD_PAYLOAD; */ CMD_RESULT(sp->cmd) = DID_ERROR << 16;