Received: by 10.223.185.116 with SMTP id b49csp3825475wrg; Mon, 19 Feb 2018 06:39:19 -0800 (PST) X-Google-Smtp-Source: AH8x225NyHlmA347T/VBzj/ApD0Dj8deL4unQBdTf1H9Bh+EU07qyQKtRRNP1pJFAy/sHL1wmH+d X-Received: by 2002:a17:902:2e03:: with SMTP id q3-v6mr14639636plb.362.1519051158915; Mon, 19 Feb 2018 06:39:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519051158; cv=none; d=google.com; s=arc-20160816; b=emdLAm7WKpn6Y7POs7vIzEE9KsjDSpW3MVMh7IwvZKxGm66O+UmggT3p0A0At6AvT1 6neyo8Imagm+SlRizRulEGNXKgsxvo/WL0CQDcx1b1nYGhn69/w2yhmJo5zUtb2EMahO T/0iJFVxEhhvBXRMOgzSocGUpXfk80uRfay+/43abisNtXDjBiHOQA2GjoPk9XCAlMaf 7CxU+ZFKB15SpB8bEbIw1WhONPvt1GObk3m3DbYXorOGQstPrCTOpb6Hf+dGk0Xiqzm+ ztycrBWNTQtW5MH+gWUWpY6IH/HEIb+Q5GlPW4kkbI1J3vxw1LzLSvXyAlXraROM9rs8 SejQ== 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=JShsbfRIsJwWQ6+hl1JM0GdlQbwLdg7tgoDV1Kb6LkY=; b=kALVX/tkpMZ81yui6HGualJZvmUtvswvTIJR+cYeuReslrG/YRzWo0hLvnyU5YZkCc sbkTmLiyfGiPZgeNtwDyh8gLLi7XFvZyS9VWvGaTtMQBc1E8iQDmFzWP1Nyzlp2mFgsO AMLQtC0iyqJ8EZxgq8iwAyc03RVeE2jZlMwVTNbbM3XoedqFP3q2L9gF+7MVFqsb/E5d jp8gCcDWiKbssZMJ59POu2+u2y0RCGZ+pYHUdeyXC3gsIS9ppPQTESf48gy979X4EYPP 2h+pOymW2EyuF5J9yzSRjDQlSUHxxOvIJpRjQ1+PFbhMNItCEOzEjoAJhJinZMSpY0Zx qegg== 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 b22si1272908pfi.244.2018.02.19.06.39.03; Mon, 19 Feb 2018 06:39:18 -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 S1752751AbeBSOi0 (ORCPT + 99 others); Mon, 19 Feb 2018 09:38:26 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59912 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751429AbeBSOiZ (ORCPT ); Mon, 19 Feb 2018 09:38:25 -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 6696F1529; Mon, 19 Feb 2018 06:38:25 -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 DDF6F3F41F; Mon, 19 Feb 2018 06:38:23 -0800 (PST) Date: Mon, 19 Feb 2018 14:38:21 +0000 From: Catalin Marinas To: Shanker Donthineni Cc: Will Deacon , linux-kernel , linux-arm-kernel , kvmarm , Marc Zyngier , Philip Elcan , Vikram Sethi Subject: Re: [PATCH] arm64: Add support for new control bits CTR_EL0.IDC and CTR_EL0.IDC Message-ID: <20180219143820.5oxc2kendvq4bbtt@armageddon.cambridge.arm.com> References: <1518829066-3558-1-git-send-email-shankerd@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518829066-3558-1-git-send-email-shankerd@codeaurora.org> 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 Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote: > Two point of unification cache maintenance operations 'DC CVAU' and > 'IC IVAU' are optional for implementors as per ARMv8 specification. > This patch parses the updated CTR_EL0 register definition and adds > the required changes to skip POU operations if the hardware reports > CTR_EL0.IDC and/or CTR_EL0.IDC. > > CTR_EL0.DIC: Instruction cache invalidation requirements for > instruction to data coherence. The meaning of this bit[29]. > 0: Instruction cache invalidation to the point of unification > is required for instruction to data coherence. > 1: Instruction cache cleaning to the point of unification is > not required for instruction to data coherence. > > CTR_EL0.IDC: Data cache clean requirements for instruction to data > coherence. The meaning of this bit[28]. > 0: Data cache clean to the point of unification is required for > instruction to data coherence, unless CLIDR_EL1.LoC == 0b000 > or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000). > 1: Data cache clean to the point of unification is not required > for instruction to data coherence. There is a difference between cache maintenance to PoU "is not required" and the actual instructions being optional (i.e. undef when executed). If your caches are transparent and DC CVAU/IC IVAU is not required, these instructions should behave as NOPs. So, are you trying to improve the performance of the cache maintenance routines in the kernel? If yes, please show some (relative) numbers and a better description in the commit log. On the patch, I'd rather have an alternative framework entry for no VAU cache maint required and some ret instruction at the beginning of the cache maint function rather than jumping out of the loop somewhere inside the cache maintenance code, penalising the CPUs that do require it. -- Catalin