Received: by 10.213.65.68 with SMTP id h4csp22888imn; Fri, 16 Mar 2018 16:06:07 -0700 (PDT) X-Google-Smtp-Source: AG47ELtagchPoRsKA5cRq2tF7wRw2pu1e9F7/x0pCOkzM3l3M6cDgNC+VRXie691ZZqZo44c6SV+ X-Received: by 2002:a17:902:3a3:: with SMTP id d32-v6mr3886246pld.219.1521241567853; Fri, 16 Mar 2018 16:06:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521241567; cv=none; d=google.com; s=arc-20160816; b=fggW/6adXlUpF+BEMe1hNGCjAfi+0oU9KsPgt5z3wFfrSOKDpVEqzGVRF7VNEkgr8S rYTy2NBX8p9NfhjYichAr/H0gst4mngHIeWzBFxJThm2WluPPk/2DYpaIMvjdh82BC9A EzoQTAM0tYPc9It1UwQPSH2tqUs7VU5wpTufX7UOcIVQQS3g5Ywp9kTM0ByVp7wgmTeh +1NqR3dRgxO55SPspwvhnyeMRoPMA8HAGPCk7GpFGw7VOjzSw+ZnlYvubNetCu7T45Ms B58mrCrQNgk4I66RUrhzRcRpd7VkX/ja8wAXCE4br5Vg7yyIv29bUBx81+TPQESq8hrQ kaYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:arc-authentication-results; bh=XVkGmo+HK3Zkx05M40q9fxtmN//j3KHz76BAJclqH+I=; b=PNlqePdG810WVnVCXKaWePFtT6qC2g7sngHk9KnO2PdnWQnBjF/T8uCrcfdDWQGP5k 0HL1vlmg/fNWvjclg0BLXgxsDkq7TX5JeaYDz1fwK4sPFj+MFpzlhWu51vK1MKSIAkE4 GU9lOvMtepR8wbxbO0CJtyOTiEB9ygrc+8F79X76fHNk8kM3mV9vcdHYk30bCddebeJs OgQh2wjN3WHY6CE9VrP252KKA76lOr9KJWRaFUQFjWqeT1yMDpmKRcXlpDEu3Ee5lrJK vyLa6YgaSb2G1+M4Emzy9R13YYTHKZegf7Puh+4DdBYXXkz1FbLlpPz0curElWIgbb9S 88EA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2si5723043pgf.658.2018.03.16.16.05.52; Fri, 16 Mar 2018 16:06:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbeCPXEn (ORCPT + 99 others); Fri, 16 Mar 2018 19:04:43 -0400 Received: from linode.aoot.com ([69.164.194.13]:54456 "EHLO linode.aoot.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbeCPXEm (ORCPT ); Fri, 16 Mar 2018 19:04:42 -0400 Received: from stevoacer (47-221-140-100.gtwncmta03.res.dyn.suddenlink.net [47.221.140.100]) by linode.aoot.com (Postfix) with ESMTP id 435CD8326; Fri, 16 Mar 2018 18:04:41 -0500 (CDT) From: "Steve Wise" To: "'Jason Gunthorpe'" Cc: "'Sinan Kaya'" , , , , , , "'Steve Wise'" , "'Doug Ledford'" , , , "'Michael Werner'" , "'Casey Leedom'" References: <1521216991-28706-1-git-send-email-okaya@codeaurora.org> <1521216991-28706-19-git-send-email-okaya@codeaurora.org> <003601d3bd6a$783d6970$68b83c50$@opengridcomputing.com> <20180316221347.GA958@ziepe.ca> In-Reply-To: <20180316221347.GA958@ziepe.ca> Subject: RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs Date: Fri, 16 Mar 2018 18:04:40 -0500 Message-ID: <004401d3bd7b$2a2e70b0$7e8b5210$@opengridcomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE6mTD+J/QLr4bfMbM+wOAMMt4Q1AI7R6heAYll0hoCtp09oKTR6VDQ Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On Fri, Mar 16, 2018 at 04:05:10PM -0500, Steve Wise wrote: > > > Code includes wmb() followed by writel(). writel() already has a barrier > > on > > > some architectures like arm64. > > > > > > This ends up CPU observing two barriers back to back before executing > the > > > register write. > > > > > > Since code already has an explicit barrier call, changing writel() to > > > writel_relaxed(). > > > > > > Signed-off-by: Sinan Kaya > > > > NAK - This isn't correct for PowerPC. For PowerPC, writeX_relaxed() is just > > writeX(). > > ?? Why is changing writex() to writeX() a NAK then? Because I want it correct for PPC as well. > > > I was just looking at this with Chelsio developers, and they said the > > writeX() should be replaced with __raw_writeX(), not writeX_relaxed(), to > > get rid of the extra barrier for all architectures. > > That doesn't seem semanticaly sane. > > __raw_writeX() should not appear in driver code, IMHO. Only the arch > code can know what the exact semantics of that accessor are.. > > If ppc can't use writel_relaxed to optimize then we probably need yet > another io accessor semantic defined :( Anybody understand why the PPC implementation of writeX_relaxed() isn't relaxed? Steve.