From: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspend
Date: Tue, 30 Jan 2024 15:10:28 +0000 [thread overview]
Message-ID: <ZbkRZNNS5WrfRpjU@e133380.arm.com> (raw)
In-Reply-To: <ca380b64-3420-4817-b3b4-584b8640c0ac@sirena.org.uk>
On Tue, Jan 30, 2024 at 02:34:23PM +0000, Mark Brown wrote:
> On Tue, Jan 30, 2024 at 10:54:06AM +0000, Dave Martin wrote:
> > On Tue, Jan 30, 2024 at 12:02:49AM +0000, Mark Brown wrote:
>
> > > + if (system_supports_sme2())
> > > + smcr |= SMCR_ELx_EZT0;
>
> > Side question: since ZT0 is likely to be sporadically used, maybe it
> > is worth having separate lazy restore for it versus the main SME state?
> > (Not relevant for this series though, and probably best deferred until
> > there is hardware to benchmark on. Also, ZT0 is small compared with
> > the SME state proper...)
>
> One of the advantages SME has here is that we've got a clear indication
> if userspace is actively using the registers through SMSTART and SMSTOP.
> We only restore ZT0 at all whenever PSTATE.ZA is set and the strong
Good point. I was still thinking in SVE mode there.
> recommendation is that should only be set when either ZA or ZT0 are in
> active use for power and performance reasons. While it is likely that
> there will be code that uses ZA but doesn't touch ZT0 I would expect
> that the overhead of entering the kernel to do a lazy restore will be
> sufficiently high for it to be an unreasonable penalty on code that does
> touch it, as you say it's not *that* big compared to likely ZA sizes.
Agreed.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2024-01-30 15:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 0:02 [PATCH 0/2] arm64/sme: Fix handling of traps on resume Mark Brown
2024-01-30 0:02 ` [PATCH 1/2] arm64/sme: Restore SMCR on exit from suspend Mark Brown
2024-01-30 10:53 ` Dave Martin
2024-01-30 12:25 ` Mark Brown
2024-01-30 12:42 ` Mark Brown
2024-01-30 0:02 ` [PATCH 2/2] arm64/sme: Restore SMCR_EL1.EZT0 " Mark Brown
2024-01-30 10:54 ` Dave Martin
2024-01-30 14:34 ` Mark Brown
2024-01-30 15:10 ` Dave Martin [this message]
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=ZbkRZNNS5WrfRpjU@e133380.arm.com \
--to=dave.martin@arm.com \
--cc=Jackson.Cooper-Driver@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
/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).