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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 74043C07E99 for ; Mon, 5 Jul 2021 12:54:01 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 33515613C2 for ; Mon, 5 Jul 2021 12:54:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33515613C2 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=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=pMZxv76no6T+/+oulg0uhi3flIgakbye3UK3yVRwE/Q=; b=uqad0oF8d1pzFs djDGGYcMIyQOAxJ+3MnrpaNqh49uf6YK4VGNt5LGDoEvyx4/L6PfRpLRU3km4YnLjX0JgoDluhvDQ 7GeT7mj9dAgK6GdB+g3wMPvJuxAZJJF3H/aGO1JMxvd4AivIqrsfi5QIkX/H/QTFonI8VWeyMW0Pc 1YCD48dUxPgBQu+3EXiOj8/PbRZH4C1zrUANEmlwmF57EqnSDgpgkF6hgE2OY+aQnwau5VqPRGxhv G+3WerZpDBX02nFOusdR6aNJhT3Corn2NvJvmflMtgML6fTb2MN9sBeuVTReTz3T4oz+U4TAbAUkn 1dJ2v5ljMNDLgFxkFDnQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m0O5V-008wo6-Hs; Mon, 05 Jul 2021 12:52:37 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m0O5R-008wnQ-T3 for linux-arm-kernel@lists.infradead.org; Mon, 05 Jul 2021 12:52:35 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CC1806101C; Mon, 5 Jul 2021 12:52:31 +0000 (UTC) Date: Mon, 5 Jul 2021 13:52:19 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Vincenzo Frascino , Will Deacon , Andrey Konovalov , Evgenii Stepanov , Szabolcs Nagy , Tejas Belagod , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] arm64: mte: switch GCR_EL1 on task switch rather than entry/exit Message-ID: <20210705125217.GA4799@arm.com> References: <20210702194518.2048539-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210702194518.2048539-1-pcc@google.com> 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-20210705_055233_999642_8DF3DDF0 X-CRM114-Status: GOOD ( 16.74 ) 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, Jul 02, 2021 at 12:45:18PM -0700, Peter Collingbourne wrote: > Accessing GCR_EL1 and issuing an ISB can be expensive on some > microarchitectures. To avoid taking this performance hit on every > kernel entry/exit, switch GCR_EL1 on task switch rather than > entry/exit. This is essentially a revert of commit bad1e1c663e0 > ("arm64: mte: switch GCR_EL1 in kernel entry and exit"). As per the discussion in v1, we can avoid an ISB, though we are still left with the GCR_EL1 access. I'm surprised that access to a non self-synchronising register is that expensive but I suspect the benchmark is just timing a dummy syscall. I'm not asking for numbers but I'd like to make sure we don't optimise for unrealistic use-cases. Is something like a geekbench score affected for example? While we can get rid of the IRG in the kernel, at some point we may want to use ADDG as generated by the compiler. That too is affected by the GCR_EL1.Exclude mask. > This requires changing how we generate random tags for HW tag-based > KASAN, since at this point IRG would use the user's exclusion mask, > which may not be suitable for kernel use. In this patch I chose to take > the modulus of CNTVCT_EL0, however alternative approaches are possible. So a few successive mte_get_mem_tag() will give the same result if the counter hasn't changed. Even if ARMv8.6 requires a 1GHz timer frequency, I think an implementation is allowed to count in bigger increments. I'm inclined to NAK this patch on the grounds that we may need a specific GCR_EL1 configuration for the kernel. Feedback to the microarchitects: make access to this register faster. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel