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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BE107C54E76 for ; Fri, 6 Jan 2023 17:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=S2HjRiMzQdjcM6PyqxAwIXZp4M/9rXncQwdTVquviiw=; b=cNgOZUK1oRC3qb uQABfcfZpJ/I28SEgcM2x+NvI1476YnebYoySFkWYhab6b6BCMy+i/fjlocU1lYMYXkZazKifmgv+ lmcN3RVn9wy2YcHWstu5V4r1GMyB1kmx41LZvHM2IdTn8eDbkRD+CdwNkJYbgaULUrEcmd8q7oO8B Xgo4bRuXrDyGNhWsSa2hTKR3ZqcPDnZtaDqeTkcoBKVzoCxiim+bNqWsc7VH2hHvYfnCjnJfUbB88 Mktr84v1x02+expQCiu5Mm7WhFkO47QVn9Cx5m2NIKdwE+5W43943rpxP9a34Rz3s4aOPVMNlmY/A EHfsou2rkoKYqXIxdumQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDqP6-00BTSW-Ao; Fri, 06 Jan 2023 17:21:16 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDqE9-00B6mS-RB for linux-arm-kernel@lists.infradead.org; Fri, 06 Jan 2023 17:10:00 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 602D2B81E1D; Fri, 6 Jan 2023 17:09:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 283FFC433EF; Fri, 6 Jan 2023 17:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673024995; bh=F+XZj/xSu8VXqvbIKNfJh4lqK02SBMgay0cVTQE7iLY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nYxJeZBeASbsGpp3Fbrc88w9nSd8f3lGTSBmGUzpdZUSq8nDy8hWDxf1m8JCpIrLt yvU/vGVavMDgqUal/hfwyM9z+9lvmjF+fvCVwwnONRi2ybpoSRhdjtztxF8GNTE0zw mT0MlgkjkxqLSgCE5nkmkjM5csAAfFTBTPATDOUPfqTYJ+l6TujKBTDG1WaDisKLzI Hye5iGerFlaMToENNdeg2Dg4psg/Ca7SVxpaRPdVnCMKMrSDDxiqRHxJCrP3byCkgB R5Ae1mFg4cf6R7c9OO6fNuYSgRqiShvyoxKbvwX22f59Yw3uH5LIEu4aJKQhMbhJQE ozEonZDjlivMw== Date: Fri, 6 Jan 2023 17:09:50 +0000 From: Will Deacon To: Gabriel Krisman Bertazi Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, broonie@kernel.org Subject: Re: [RFC PATCH] arm64: Cache HW update of Access Flag support Message-ID: <20230106170949.GA5019@willie-the-truck> References: <20230106163825.4812-1-krisman@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230106163825.4812-1-krisman@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230106_090958_252439_9DA15DA7 X-CRM114-Status: GOOD ( 36.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Fri, Jan 06, 2023 at 01:38:25PM -0300, Gabriel Krisman Bertazi wrote: > Accessing AA64MMFR1_EL1 is expensive in KVM guests, since it is emulated > in the hypervisor. In fact, ARM documentation mentions some feature > registers are not supposed to be accessed frequently by the OS, and > therefore should be emulated for guests [1]. > > Commit 0388f9c74330 ("arm64: mm: Implement > arch_wants_old_prefaulted_pte()") introduced a read of this register in > the page fault path. But, even when the feature of setting faultaround > pages with the old flag is disabled for a given cpu, we are still paying > the cost of checking the register on every pagefault. This results in an > explosion of vmexit events in KVM guests, which directly impacts the > performance of virtualized workloads. For instance, running kernbench > yields a 15% increase in system time solely due to the increased vmexit > cycles. > > This patch avoids the extra cost by caching the register value after the > first read. It should be safe to do so, since this register mustn't > change for a specific processor. > > As a side note, we can't rely on the usual cpucap for this bit, because > for some reason that I'm missing, it is always enabled for aarch64, even if > the functionality is not supported by the processor. > > [1] https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Armv8-A%20virtualization.pdf?revision=a765a7df-1a00-434d-b241-357bfda2dd31 > > Signed-off-by: Gabriel Krisman Bertazi > --- > arch/arm64/include/asm/cpufeature.h | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > index 03d1c9d7af82..599c7a22155b 100644 > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -859,14 +859,24 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange) > /* Check whether hardware update of the Access flag is supported */ > static inline bool cpu_has_hw_af(void) > { > - u64 mmfr1; > + static unsigned int has_af = -1U; > > if (!IS_ENABLED(CONFIG_ARM64_HW_AFDBM)) > return false; > > - mmfr1 = read_cpuid(ID_AA64MMFR1_EL1); > - return cpuid_feature_extract_unsigned_field(mmfr1, > + /* > + * Cache the register to avoid repeatedly reading it, > + * which is an emulated operation on KVM guests. > + * > + * Also do not rely on cpucap, since this bit is always set > + * there, regardless of actual status. See has_hw_dbm() for > + * details. > + */ > + if (unlikely(has_af == -1U)) > + has_af = cpuid_feature_extract_unsigned_field( > + read_cpuid(ID_AA64MMFR1_EL1), > ID_AA64MMFR1_EL1_HAFDBS_SHIFT); > + return has_af; The intention here was to read the value for the _current_ CPU, since it might not be the same across the system when big.MISTAKE gets involved. However, since this is really just a performance optimisation and I think that the access flag tends to be uniformly supported in practice anyway, the best bet is probably just to read the sanitised version of the field using read_sanitised_ftr_reg(). Can you give that a shot, please? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel