On Mon, Jul 31, 2017 at 11:20:59PM +1000, Michael Ellerman wrote: > Peter Zijlstra <[email protected]> writes:
> > In fact, I'm fairly sure its only PPC. > > > > Because only ARM64 and PPC actually implement ACQUIRE/RELEASE with > > anything other than smp_mb() (for now, Risc-V is in this same boat and > > MIPS could be if they ever sort out their fancy barriers). > > > > TSO archs use a regular STORE for RELEASE, but all their atomics imply a > > smp_mb() and there are enough around to make one happen (typically > > mm_cpumask updates). > > > > Everybody else, aside from ARM64 and PPC must use smp_mb() for > > ACQUIRE/RELEASE. > > > > ARM64 has a super duper barrier in switch_to(). > > > > Which only leaves PPC stranded.. but the 'good' news is that mpe says > > they'll probably need a barrier in switch_mm() in any case. > > I may have been sleep deprived. We have a patch, probably soon to be > merged, which will add a smp_mb() in switch_mm() but *only* when we add > a CPU to mm_cpumask, ie. when we run on a CPU we haven't run on before. > > I'm not across membarrier enough to know if that's sufficient, but it > seems unlikely? Correct, that would be insufficient. We'd need it every time switch_mm() does indeed change the effective mm. Now you also spoke of looking at clearing bits in mm_cpumask(), and I suspect that if you do that, you end up having to do a barrier every time.
