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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,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 4C676C433DB for ; Fri, 29 Jan 2021 13:55:59 +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 E5DEF64DD9 for ; Fri, 29 Jan 2021 13:55:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5DEF64DD9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HOATZFyU5fi/2nVrRlqvW/1xu2SHgzVcvBjTMcIjcPI=; b=h3EX7BaUWb/D/iN6r43NuZ3ju z2dMXCrJZFZtOycSjAQ0Pstl32WYWK0sCPT3VLYVkQwK/WUsaBeI5+5PbBIbCtnghhSMKLBvf+uv9 noMkr2eW89jLz9GlpyZycux5feFNqBojQZDN6IE7Kl5m48xcx/F/zSFM9Uu2zdJnRdtFtV4RGfr+n 0pyeaGxFzqZTEdUS4+Ox4uuWH9GYNI37eIEduUgKa+X39zaU6yl9dNcQL5Ac9TL3UhZugHM0Z/kFc q2ciU2LtklVGQUFKmt9uN8KF5eVIcYZ/AkiXzNZc5VJG1oV9rfzH+8fYrq4qgebbXqJ0Hru9ti5Yb bLau4SDQg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5UEY-00047p-M8; Fri, 29 Jan 2021 13:54:46 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5UEV-00047H-29 for linux-arm-kernel@lists.infradead.org; Fri, 29 Jan 2021 13:54:44 +0000 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DRzLl4F5MzMR25; Fri, 29 Jan 2021 21:53:03 +0800 (CST) Received: from [127.0.0.1] (10.174.176.220) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Fri, 29 Jan 2021 21:54:29 +0800 Subject: Re: [PATCH v5 4/4] ARM: Add support for Hisilicon Kunpeng L3 cache controller To: Arnd Bergmann References: <20210116032740.873-1-thunder.leizhen@huawei.com> <20210116032740.873-5-thunder.leizhen@huawei.com> <20dac713-25b7-cddf-cc42-69a834487c71@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <6c4d3650-0040-06d4-4342-79392738877b@huawei.com> Date: Fri, 29 Jan 2021 21:54:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.176.220] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210129_085443_605775_394FD9DE X-CRM114-Status: GOOD ( 28.71 ) 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: devicetree , Arnd Bergmann , Greg Kroah-Hartman , Will Deacon , linux-kernel , Haojian Zhuang , Rob Herring , Wei Xu , Russell King , linux-arm-kernel 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 2021/1/29 18:26, Arnd Bergmann wrote: > On Fri, Jan 29, 2021 at 9:16 AM Arnd Bergmann wrote: >> On Fri, Jan 29, 2021 at 8:23 AM Leizhen (ThunderTown) >> wrote: >>> On 2021/1/28 22:24, Arnd Bergmann wrote: >>>> On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei wrote: >>>>> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile >>>>> + >>>>> +static void l3cache_maint_common(u32 range, u32 op_type) >>>>> +{ >>>>> + u32 reg; >>>>> + >>>>> + reg = readl(l3_ctrl_base + L3_MAINT_CTRL); >>>>> + reg &= ~(L3_MAINT_RANGE_MASK | L3_MAINT_TYPE_MASK); >>>>> + reg |= range | op_type; >>>>> + reg |= L3_MAINT_STATUS_START; >>>>> + writel(reg, l3_ctrl_base + L3_MAINT_CTRL); >>>> >>>> Are there contents of L3_MAINT_CTRL that need to be preserved >>>> across calls and can not be inferred? A 'readl()' is often expensive, >>>> so it might be more efficient if you can avoid that. >>> >>> Right, this readl() can be replaced with readl_relaxed(). Thanks. >>> >>> I'll check and correct the readl() and writel() in other places. >> >> What I meant is that if you want to replace them, you should provide >> performance numbers that show how much difference this makes >> and add comments in the source code explaining how you proved that >> the _relaxed() version is actually correct. > > Another clarification, as there are actually two independent > points here: > > * if you can completely remove the readl() above and just write a > hardcoded value into the register, or perhaps read the original > value once at boot time, that is probably a win because it > avoids one of the barriers in the beginning. The datasheet should > tell you if there are any bits in the register that have to be > preserved Code coupling will become very strong. > > * Regarding the _relaxed() accessors, it's a lot harder to know > whether that is safe, as you first have to show, in particular in case > any of the accesses stop being guarded by the spinlock in that > case, and whether there may be a case where you have to > serialize the memory access against accesses that are still in the > store queue or prefetched. > > Whether this matters at all depends mostly on the type of devices > you are driving on your SoC. If you have any high-speed network > interfaces that are unable to do cache coherent DMA, any extra > instruction here may impact the number of packets you can transfer, > but if all your high-speed devices are connected to a coherent > interconnect, I would just go with the obvious approach and use > the safe MMIO accessors everywhere. In fact, this driver has been running on an earlier version for several years and has not received any feedback about the performance issue. So I didn't try to optimize it when I first sent these patches. I had to reconsider it until you noticed it. How about keeping it unchanged for the moment? It'll take a lot of time and energy to retest. > > Arnd > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel