Received: by 10.223.185.116 with SMTP id b49csp3533755wrg; Tue, 13 Feb 2018 03:59:17 -0800 (PST) X-Google-Smtp-Source: AH8x226OJUf2Up8nhYL/ziIiauIEWiRe9a2qmGWjjg+xMx+4+Hq/MzTnnR9HSFGfl+Z/o6Qp43S2 X-Received: by 2002:a17:902:8a89:: with SMTP id p9-v6mr882318plo.397.1518523157173; Tue, 13 Feb 2018 03:59:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518523157; cv=none; d=google.com; s=arc-20160816; b=HRiv82ugGfn4qdkmfMYOmINtWtpAAF8ENYeRfdQcq4X7n02A3U/goVnh66XvZrMHEh YRhNFSWkeYda0pgTqlIYViLU9G8CERWDucOArDVSFG/2ElD+22GYhZzNjuDKvEqrPWvs FaiMIg25Ga+UjuRSgnLJCZYvDJQ6syJd2pu8ZflZte+dztPWiNJX9/6FZJY9oJWcFxLL XbB3oKsWNG360pvl1xyXNRgNFCy5KEppUKUU0iwJVpJmpm6ks1EzXkar48FNgTBeiOWZ 1nf0nb+4wJQ0/LkhhC/YLKrFT6SFc8+GaoDocT4HyCjyQvG4ch+SPnwX1P5Tp+tJwrcG htlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=v4GGcK/dSNnCeQdSowvWORRmSou0em+CfqFhlCxXU5Q=; b=srklpzCaOXicAj/SeKKrjN/AB72KWoyhphlci9oV6uxc0a1nDLsfY1Fdqxaujbp6hL QyblYInEhSw5hvxxUNDwuCPkE8QD1fuHmdX0vD8FU9iWOipD9tCnkyWM1wXSl3hqEmT/ Pl13PqXF6zj5e3gcemKR3YxDQY0Mx6bKFea4wvCK6VEb59rc6500w7Eu28wxVlndoEDC Ie8p+wT+u1abyINIZnDXVOYATTICBCYBJUBnqc0pMgxpAUyYbEI5y1bBwttsIo7fM4I+ VrQYTxxRe0SRXQv0IEcIZOCyi36Qt9I4LDA7baPC4Do802J6ooWsEH9BAgqmwFf0v8F9 aO4Q== 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 y20si4992686pgv.723.2018.02.13.03.59.02; Tue, 13 Feb 2018 03:59:17 -0800 (PST) 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 S934963AbeBML5X (ORCPT + 99 others); Tue, 13 Feb 2018 06:57:23 -0500 Received: from foss.arm.com ([217.140.101.70]:55876 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934733AbeBML5W (ORCPT ); Tue, 13 Feb 2018 06:57:22 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 250381435; Tue, 13 Feb 2018 03:57:22 -0800 (PST) Received: from armageddon.cambridge.arm.com (armageddon.cambridge.arm.com [10.1.206.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7BF4D3F53D; Tue, 13 Feb 2018 03:57:20 -0800 (PST) Date: Tue, 13 Feb 2018 11:57:17 +0000 From: Catalin Marinas To: Florian Fainelli Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland , timur@codeaurora.org, Will Deacon , open list , rrichter@cavium.com, tchalamarla@cavium.com, opendmb@gmail.com Subject: Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable Message-ID: <20180213115717.4ubsnjraacorwbgk@armageddon.cambridge.arm.com> References: <1518479125-14428-1-git-send-email-f.fainelli@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518479125-14428-1-git-send-email-f.fainelli@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 12, 2018 at 03:45:23PM -0800, Florian Fainelli wrote: > On many platforms, including, but not limited to Brahma-B53 platforms, > the L1 cache line size is 64bytes. Increasing the value to 128bytes > appears to be creating performance problems for workloads involving > network drivers and lots of data movement. In order to keep what was > introduced with 97303480753e ("arm64: Increase the max granular size"), > a kernel built for ARCH_THUNDER or ARCH_THUNDER2 will get a 128bytes > cache line size definition. This approach has been raised before ([1] as an example but you can probably find other threads) and NAK'ed. I really don't want this macro to be configurable as we aim for a single kernel Image. My proposal was to move L1_CACHE_SHIFT back to 6 and ARCH_DMA_MIN_ALIGN to 128 as this is the largest known CWG. The networking code is wrong in assuming SKB_DATA_ALIGN only needs SMP_CACHE_BYTES for DMA alignment but we can add some safety checks (i.e. WARN_ON) in the arch dma ops code if the device is non-coherent. I'll send a patch to the list (hopefully later today). Catalin [1] https://patchwork.kernel.org/patch/8634481/