[PATCH] arm64/fpsimd: Ensure we don't contend a SMCU from idling CPUs

[Mark Brown]

On Thu, Sep 05, 2024 at 06:51:30PM +0100, Catalin Marinas wrote:

> OK, so likely the state is already saved, all we need to do here is
> flush the state and SMSTOP. But why would switching to idle be any
> different than switching to a thread that doesn't used SME? It feels
> like we are just trying to optimise a special case only. Could we not
> instead issue an SMSTOP in the context switch code?

On context switch the SMSTOP is issued as part of loading the state for
the task but we only do that when either returning to userspace or it's
a kernel thread with active FPSIMD usage.  The idle thread is a kernel
thread with no FPSIMD usage so we don't touch the state.  If we did the
SMSTOP unconditionally that'd mean that the optimisation where we don't
reload the FP state if we bounce through a kernel thread would be broken
while using SME which doesn't seem ideal, idling really does seem like a
meaningfully special case here.

> Also this looks hypothetical until we have some hardware to test it on,
> see how it would behave with a shared SME unit.

The specific performance impacts will depend on hardware (there'll
likely be some power impact even on things with a single FP unit per
PE) but given that keeping SM and ZA disabled when not in use is a
fairly strong recommendation in the programming model my inclination at
this point would be to program to the advertised model until we have
confirmation that the hardware actually behaves otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240905/bf796c37/attachment.sig>