On Tue, 2019-04-02 at 17:19 +1100, Michael Ellerman wrote: > > Joakim Tjernlund <joakim.tjernl...@infinera.com> writes: > > On Fri, 2019-03-29 at 22:26 +1100, Michael Ellerman wrote: > > > From: Diana Craciun <diana.crac...@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.crac...@nxp.com> > > > [mpe: Split out of larger patch] > > > Signed-off-by: Michael Ellerman <m...@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
