From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965976AbcCPNHS (ORCPT ); Wed, 16 Mar 2016 09:07:18 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57788 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934166AbcCPNHO (ORCPT ); Wed, 16 Mar 2016 09:07:14 -0400 Subject: Re: [PATCH] Revert "arm64: Increase the max granular size" To: Will Deacon , Ganesh Mahendran Cc: catalin.marinas@arm.com, stable@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tchalamarla@cavium.com, rrichter@cavium.com, apinski@cavium.com, Shanker Donthineni References: <1458120743-12145-1-git-send-email-opensource.ganesh@gmail.com> <20160316100759.GA18387@arm.com> From: Timur Tabi Message-ID: <56E95A4E.4050709@codeaurora.org> Date: Wed, 16 Mar 2016 08:06:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <20160316100759.GA18387@arm.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 Will Deacon wrote: > [adding Cavium folk and Timur] > > On Wed, Mar 16, 2016 at 05:32:23PM +0800, Ganesh Mahendran wrote: >> Reverts commit 97303480753e ("arm64: Increase the max granular size"). >> >> The commit 97303480753e ("arm64: Increase the max granular size") will >> degrade system performente in some cpus. >> >> We test wifi network throughput with iperf on Qualcomm msm8996 CPU: >> ---------------- >> run on host: >> # iperf -s >> run on device: >> # iperf -c -t 100 -i 1 >> ---------------- >> >> Test result: >> ---------------- >> with commit 97303480753e ("arm64: Increase the max granular size"): >> 172MBits/sec >> >> without commit 97303480753e ("arm64: Increase the max granular size"): >> 230MBits/sec >> ---------------- >> >> Some module like slab/net will use the L1_CACHE_SHIFT, so if we do not >> set the parameter correctly, it may affect the system performance. >> >> So revert the commit. > > Unfortunately, the original patch is required to support the 128-byte L1 > cache lines of Cavium ThunderX, so we can't simply revert it like this. > Similarly, the desire for a single, multiplatform kernel image prevents > us from reasonably fixing this at compile time to anything other than > the expected maximum value. > > Furthermore, Timur previously said that the change is also required > "on our [Qualcomm] silicon", but I'm not sure if this is msm9886 or not: > > http://lkml.kernel.org/r/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com I was talking about our server part, the QDF2432. At the time, I wasn't allowed to mention it by name. > You could look into making ARCH_DMA_MINALIGN a runtime value, but that > looks like an uphill struggle to me. Alternatively, we could only warn > if the CWG is bigger than L1_CACHE_BYTES *and* we have a non-coherent > DMA master, but that doesn't solve any performance issues from having > things like locks sharing cachelines, not that I think we ever got any > data on that (afaik, we don't pad locks to cacheline boundaries anyway). > I'm also not sure what it would mean for PCI NoSnoop transactions. Our internal version of this patch made it a Kconfig option. Perhaps that would at least be an improvement over just reverting it? We already have to have our own defconfig for the QDF2432. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation.