Kernelspace C11 atomics for MIPS

[Andrew Duane]

> -----Original Message-----
> From: owner-freebsd-mips at freebsd.org [mailto:owner-freebsd-
> mips at freebsd.org] On Behalf Of Juli Mallett
> Sent: Monday, June 03, 2013 11:55 PM
> To: Adrian Chadd
> Cc: Ed Schouten; freebsd-mips at FreeBSD.org; FreeBSD-arch
> Subject: Re: Kernelspace C11 atomics for MIPS
> 
> On Mon, Jun 3, 2013 at 7:45 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> 
> > Speaking of this; any idea why the SYNC operators have 8 NOPs following
> > them?
> >
> > I noticed that when going through disassemblies of various mips24k .o
> > files.
> >
> 
> To drain the pipeline on certain deficient (and mostly older) CPUs by way
> of guesswork and a little vague magic.  Most CPUs we support, I would
> guess, do not need this, and it continues to exist solely for
> hysterical reasons.
> 
> I've certainly gotten rid of them and some other cargo cult synchronization
> on Octeon for testing and had it survive under considerable load, and
> occasionally with some slight speedups (for some more commonly-used or
> slower things than Just a Bunch Of NOPs.)
> 
> The trouble is that proving they aren't necessary requires being rigorous
> and careful in understanding documentation and errata, and FUD about their
> possible necessity is somewhat-intimidating.  It's not an easy kind of
> corruption/unreliability/etc., to prove the lack of empirically.

The various CPU types are supposed to specify exactly how many NOPs are needed, what kind of barrier is needed and where, and which type of NOP is needed (Alpha had at least two). The barriers are designed to insure correct operation ordering across the memory architectures including write buffers, DMA hardware, L1/L2[/L3] caches and their connections to the cores. The CPU should specify exactly what is needed where, and why. It should never be "superstition". There is an exact hardware reason for every sync/barrier operation, and every NOP needed, just like the COP0 hazards.

Given that, Juli's last paragraph is right on point. The documentation can be dense and difficult to understand, since it's usually written by hardware engineers :-) And since getting it wrong can make for some really subtle, intermittent, and incredibly hard to diagnose problems, it's easier to err on the side of caution. It also happens that different CPUs included in a certain compile switch may have different requirements, so you have to use worst case.

> 
> Juli.
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
> 


 ....................................
Andrew L. Duane
Resident Architect - AT&T Technical Lead
m   +1 603.770.7088
o   +1 408.933.6944 (2-6944)
skype: andrewlduane
aduane at juniper.net