From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: mte: optimize asynchronous tag check fault flag check
Date: Wed, 18 Nov 2020 11:23:55 +0000 [thread overview]
Message-ID: <X7UES4okKmoMRtma@trantor> (raw)
In-Reply-To: <20201118032051.1405907-1-pcc@google.com>
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
next prev parent reply other threads:[~2020-11-18 11:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 3:20 [PATCH] arm64: mte: optimize asynchronous tag check fault flag check Peter Collingbourne
2020-11-18 11:23 ` Catalin Marinas [this message]
2020-11-18 16:53 ` Peter Collingbourne
2020-11-18 17:07 ` Catalin Marinas
2020-11-18 17:48 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X7UES4okKmoMRtma@trantor \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pcc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).