From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Ryan Roberts <Ryan.Roberts@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/2] arm64/sve: Performance improvements with SVE state saving
Date: Wed, 13 May 2026 10:18:55 +0900 [thread overview]
Message-ID: <agPRf9XTQPwyA3n_@sirena.co.uk> (raw)
In-Reply-To: <agM03CN6cX2JNu62@willie-the-truck>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
On Tue, May 12, 2026 at 03:10:36PM +0100, Will Deacon wrote:
> On Fri, Mar 20, 2026 at 03:44:13PM +0000, Mark Brown wrote:
> > The two patches here move to using a time based heuristic to decide when
> > to reenable the SVE access trap, doing so after a second. This means
> > that tasks actively using SVE which block in syscalls should see reduced
> > or similar numbers of access traps, while CPU bound tasks that rarely
> > use SVE will see the SVE syscall overhead removed after running for
> > approximately a second, confirmed via fp-pidbench.
> Have you looked at all at applying this heuristic to SME? I wonder if it
> would help with the recent DVMSync erratum workaround, where tasks that
> use SME once/infrequently end up causing IPIs for TLB invalidation every
> time they run on an effected core.
I have not done so myself, though I did discuss this with Catalin while
he was working on those workarounds. IIRC he wanted to get a better
picture of the system level costs with actual usage before deciding if
it was a good tradeoff, either to do this at all or to see if we can
skip the timeout based approach or could just reenable SME traps
whenever we see SME is not in use.
With SME it's easier because you can directly tell if the task currently
has SME enabled so I'd expect the checks on state load are enough and we
don't need to put anything into the syscall path, it's likely that the
tradeoffs for doing that don't work out so well.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2026-05-13 1:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 15:44 [PATCH v8 0/2] arm64/sve: Performance improvements with SVE state saving Mark Brown
2026-03-20 15:44 ` [PATCH v8 1/2] arm64/fpsimd: Suppress SVE access traps when loading FPSIMD state Mark Brown
2026-03-20 15:44 ` [PATCH v8 2/2] arm64/sve: Disable TIF_SVE on syscall once per second Mark Brown
2026-05-12 14:10 ` [PATCH v8 0/2] arm64/sve: Performance improvements with SVE state saving Will Deacon
2026-05-13 1:18 ` Mark Brown [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=agPRf9XTQPwyA3n_@sirena.co.uk \
--to=broonie@kernel.org \
--cc=Mark.Rutland@arm.com \
--cc=Ryan.Roberts@arm.com \
--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