On Tue, 2019-04-02 at 17:19 +1100, Michael Ellerman wrote:
Joakim Tjernlund Joakim.Tjernlund@infinera.com writes:
On Fri, 2019-03-29 at 22:26 +1100, Michael Ellerman wrote:
From: Diana Craciun diana.craciun@nxp.com
commit ebcd1bfc33c7a90df941df68a6e5d4018c022fba upstream.
Implement the barrier_nospec as a isync;sync instruction sequence. The implementation uses the infrastructure built for BOOK3S 64.
Signed-off-by: Diana Craciun diana.craciun@nxp.com [mpe: Split out of larger patch] Signed-off-by: Michael Ellerman mpe@ellerman.id.au
What is the performanc impact of these spectre fixes?
I've not seen any numbers from anyone.
Thanks for getting back to me.
It will depend on the workload, it's copy to/from user that is most likely to show an impact.
We have a context switch benchmark in tools/testing/selftests/powerpc/benchmarks/context_switch.c.
Running that with "--no-vector --no-altivec --no-fp --test=pipe" shows about a 2.3% slow down vs booting with "nospectre_v1".
Can I compile it away?
You can't actually, but you can disable it at runtime with "nospectre_v1" on the kernel command line.
We could make it a user selectable compile time option if you really want it to be.
I think yes. Considering that these patches are fairly untested and the impact in the wild unknown. Requiring systems to change their boot config over night is too fast.
Jocke