Re: [PATCH v2 7/7] arm64/sve: Don't zero non-FPSIMD register state on syscall by default
flat view
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2022-07-19 17:36:49
Also in:
kvmarm
Hi Mark, On Mon, Jun 20, 2022 at 01:41:58PM +0100, Mark Brown wrote:
The documented syscall ABI specifies that the SVE state not shared with FPSIMD is undefined after a syscall. Currently we implement this by always flushing this register state to zero, ensuring consistent behaviour but introducing some overhead in the case where we can return directly to userspace without otherwise needing to update the register state. Take advantage of the flexibility offered by the documented ABI and instead leave the SVE registers untouched in the case where can return directly to userspace.
Do you have some rough numbers to quantify the gain? I suspect the vector length doesn't matter much. Where does the zeroing happen now? IIRC it's only done on a subsequent trap to SVE and that's a lot more expensive (unless the code has changed since last time I looked). So if it's the actual subsequent trap that adds the overhead, maybe zeroing the regs while leaving TIF_SVE on won't be that bad.
Since this is a user visible change a new sysctl abi.sve_syscall_clear_regs is provided which will restore the current behaviour of flushing the unshared register state unconditionally when enabled. This can be enabled for testing or to work around problems with applications that have been relying on the current flushing behaviour. The sysctl is disabled by default since it is anticipated that the risk of disruption to userspace is low. As well as being within the documented ABI this new behaviour mirrors the standard function call ABI for SVE in the AAPCS which should mean that compiler generated code is unlikely to rely on the current behaviour, the main risk is from hand coded assembly which directly invokes syscalls. The new behaviour is also what is currently implemented by qemu user mode emulation.
IIRC both Will and Mark R commented in the past that they'd like the current de-facto ABI to become the official one. I'll let them comment.
quoted hunk ↗ jump to hunk
@@ -183,7 +217,7 @@ static inline void fp_user_discard(void) if (!system_supports_sve()) return; - if (test_thread_flag(TIF_SVE)) { + if (sve_syscall_regs_clear && test_thread_flag(TIF_SVE)) { unsigned int sve_vq_minus_one; sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1;
If we leave TIF_SVE on, does it mean that we incur an overhead on context switching? E.g. something like hackbench with lots of syscalls communicating between threads would unnecessarily context switch the SVE state. Maybe there's something handling this but IIUC fpsimd_save() seems to only check TIF_SVE. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel