From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8939C43461 for ; Thu, 17 Sep 2020 10:30:01 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A27F2083B for ; Thu, 17 Sep 2020 10:30:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pKw+BK8X" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A27F2083B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MhJe42T0BI77HEQhy4N8aob77mRtJNsx2oolxwCYgvA=; b=pKw+BK8X+s16IVLypv1psZMqO U8v5sxBoY9e0ZizjLk+C8NuNz9KUsSXkx85QZ7OC9E01ArizvCCywL2BAowTVlORcb6CeM4TIvRvs Gd1O7rBDMhxKpdPJCH9yMSzggk7DuJP75sA7ZZkLCyO1FNcXf3qrCCx1EurypoAxElD1fJ5xQJEoI zjcVY9goCSn09q9tmTyxau8cJqEuyAmRWOkRUDqfw1sgFWuBnL2dhQAf6RAejA2MixS9xHXGp18Kx 1bBJYbC8Yr7lOJsYIPRgzt2VXYVsr6Do3btvhPA3W1obyxKhDAwEOSfAejrKQU8bCnh+omFGAe/2r IvQTnlFJg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIr9S-0006LL-Jd; Thu, 17 Sep 2020 10:28:30 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIr9Q-0006Kk-2A for linux-arm-kernel@lists.infradead.org; Thu, 17 Sep 2020 10:28:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4AC9812FC; Thu, 17 Sep 2020 03:28:26 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 15F243F68F; Thu, 17 Sep 2020 03:28:24 -0700 (PDT) Date: Thu, 17 Sep 2020 11:28:19 +0100 From: Lorenzo Pieralisi To: Benjamin Herrenschmidt Subject: Re: [PATCH] arm64: Enable PCI write-combine resources under sysfs Message-ID: <20200917102819.GA2284@e121166-lin.cambridge.arm.com> References: <1d6f2ceb8d3538c906a1fdb8cd3d4c74ccffa42e.camel@kernel.crashing.org> <20200914225740.GP904879@nvidia.com> <2b539df4c9ec703458e46da2fc879ee3b310b31c.camel@kernel.crashing.org> <20200915101831.GA2616@e121166-lin.cambridge.arm.com> <20200915110511.GQ904879@nvidia.com> <20200915234006.GI1573713@nvidia.com> <701012f288231d0d0733bf1c2c8fdbd9caa074fd.camel@kernel.crashing.org> <20200916121226.GN1573713@nvidia.com> <28082ccc715a9fba349ae6052d5c917ae02d40fa.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <28082ccc715a9fba349ae6052d5c917ae02d40fa.camel@kernel.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_062828_167153_63545D38 X-CRM114-Status: GOOD ( 24.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Leon Romanovsky , linux-pci@vger.kernel.org, Bjorn Helgaas , Jason Gunthorpe , catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, Clint Sbisa Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 17, 2020 at 09:59:28AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2020-09-16 at 09:12 -0300, Jason Gunthorpe wrote: > > > Also we could make this a variable rather than a constant and > > > choose > > > a more appropriate set of flags at boot time.... > > > > It is a function, so it could check the CPU ID for the known broken > > devices and block them. > > Sure, I meant in the abstract way. It's not a hot path so it doesnt > have to be a static key. > > > > > > Why would that be a regression ? > > > > > > > > Using the WC submission flow when it doesn't work costs something > > > > like > > > > 10% performance vs using the non-WC flow. > > > > > > You mean the driver uses a different path to the HW which ahs that > > > overhead, not that MMIOs have that overhead right ? > > > > The different path has overhead of doing extra useless MMIOs because > > they don't combine > > I see. This might have to end up being a TX2 specific hack until the > end of times... True - hopefully on platforms that implement normal NC the architectural way will not trigger user space performance regressions. Unfortunately if we merge this patch we _do_ know from this thread that userspace will suffer from a perf regression on TX2. Either we ignore it or we write some code to prevent it (ie first step make arch_can_pci_mmap_wc() return 0 on TX2 - possibly using the arm64 errata detection mechanism). Adding a new IO mapping API and use it in IB drivers won't solve the TX2 problem - since we still prefer normal NC over device GRE for "WC" mappings and we would have to "downgrade" TX2 somehow. Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel