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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 A5F44C56202 for ; Wed, 18 Nov 2020 11:24:27 +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 2D5D02075A for ; Wed, 18 Nov 2020 11:24:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mLqVJy6M" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D5D02075A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.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:References:Message-ID: Subject: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=1yxFgPSK1gbskfg9G3x/8KxLU29wGulcU8RCQw+BlRo=; b=mLqVJy6M8WjFQJsK871nRazMt 6cJwKzyrIyzTPi4vUTVIO0ObWJSjaxtQK7WS1pcanuO8/P/IZ6QYDCRkHyzTaBhLJOTLH95OwpjK4 XxwA/RpG76XZMbUlaCugni94JVCXIIsBbwt/574vFJXbD3/Ngs5cT5CowQEoNcO2EkLJeEQkZJvQr d+xoN80XP21beFf6S+xAFQoBuiLKS9Nhpn+tlYF3PJP/Vgp4mISJ5CcvSBzHAFDmlr9qAKYFZ/YJB ViOZFwaS0eaBDS7b2hkozPw6mui7RBK7AcXL5mhdfdFDn1P5RTUVlr/hZnL0K4i3YbJAn7EV+z3Zv +uESfZRZQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfLZC-0001ob-TM; Wed, 18 Nov 2020 11:24:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfLZA-0001o2-2X for linux-arm-kernel@lists.infradead.org; Wed, 18 Nov 2020 11:24:00 +0000 Received: from trantor (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CEB95206B7; Wed, 18 Nov 2020 11:23:57 +0000 (UTC) Date: Wed, 18 Nov 2020 11:23:55 +0000 From: Catalin Marinas To: Peter Collingbourne Subject: Re: [PATCH] arm64: mte: optimize asynchronous tag check fault flag check Message-ID: References: <20201118032051.1405907-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201118032051.1405907-1-pcc@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201118_062400_219747_C28B3F82 X-CRM114-Status: GOOD ( 22.36 ) 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: Linux ARM 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 Tue, Nov 17, 2020 at 07:20:51PM -0800, Peter Collingbourne wrote: > We don't need to check for MTE support before checking the flag > because it can only be set if the hardware supports MTE. As a result > we can unconditionally check the flag bit which is expected to be in > a register and therefore the check can be done in a single instruction > instead of first needing to load the hwcaps. > > On a DragonBoard 845c with a kernel built with CONFIG_ARM64_MTE=y with > the powersave governor this reduces the cost of a kernel entry/exit > (invalid syscall) from 465.1ns to 463.8ns. That's less than 0.3%, could be noise as well. > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c > index e4c0dadf0d92..f533e83fd722 100644 > --- a/arch/arm64/kernel/syscall.c > +++ b/arch/arm64/kernel/syscall.c > @@ -123,7 +123,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, > local_daif_restore(DAIF_PROCCTX); > user_exit(); > > - if (system_supports_mte() && (flags & _TIF_MTE_ASYNC_FAULT)) { > + if (IS_ENABLED(CONFIG_ARM64_MTE) && (flags & _TIF_MTE_ASYNC_FAULT)) { system_supports_mte() is actually a static label (well, it expands to two). So we get a combination of nop/branch jumping over the flags check. Maybe the difference you are seeing is caused by the extra instructions changing the cache alignment or confusing the branch predictor. I wonder whether changing __cpus_have_const_cap() to use static_branch_likely() has any effect (given that we expect most features to be enabled in future CPUs, such change would probably make sense). That said, I'm happy to take this patch, most likely it replaces some static branch with tbnz on this path. Given that MTE is on in defconfig, do we actually need the IS_ENABLED() check? If we remove it, it would be more consistent with the similar check in do_notify_resume(). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel