Kernelspace C11 atomics for MIPS

[Warner Losh]

On Jun 3, 2013, at 10:04 PM, Juli Mallett wrote:

> On Mon, Jun 3, 2013 at 8:57 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> On 3 June 2013 20:55, Juli Mallett <jmallett at freebsd.org> wrote:
> 
> > 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.
> 
> How can I turn it off for my compiles?
> 
> Edit the source.  This is not and this kind of thing must not be a user-visible go-faster knob.  I'm anticipating that someone might want to respond to "edit the source" by saying that users don't have to edit the source, without understanding the kind of change this is.

This isn't a user-visible knob. If you don't know what you are doing, then don't do it.

In the absence of errata, they aren't called out as being required.

From Linux, I could find them in the following contexts:
One of the places where sync was used in au1000 (at the end of the DO_SLEEP macro)
On octeon, syncw; syncw is used to work around CN3xxx core bugs
bmips_read_zscm_reg has a bunch of _ssnops after it. But it is unused (perhaps in retired CPUs)
au1k_wait() has them

And that's it. I think they can safely go if Linux doesn't have them :)

> > 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.)
> 
> Right. Well, since it's happening on every inlined lock, it's a bit silly.
> 
> Yes.

Yes.

> > 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.
> 
> I've checked the diassembly from gcc-4.mumble on linux; it doesn't
> include NOPs like this as far as I can tell.
> 
> Neat.
> 
> You might also like to look at usage of 'sync' (and its variants, or the lack of use of its variants) and the possibility of using newer mips32/64 instructions to change whether interrupts are enabled, and a number of other things, at least for certain CPU types.   

Yes, that would be awesome...

> And excessive use of all kinds of memory barriers (including simple memory-clobber barriers) and and and.  There's a lot of small changes that can be made that add up, but building confidence across the range of hardware we support is genuinely-hard.

Yes, we need read barrier, write barrier and general memory barrier better in the tree. And MIPS' implementation needs to improve.

I think they date to the very earliest days of the port (and predate the Juniper MIPS merge)...  If you look at svn blame, it says:
178172        imp 			"nop\n\t"
for all of them. I have no clue where they came from. Looking at the svn log, it appears they came from the mips2 branch, which may or may not have been before or after the Juniper code base was merged in.

I think they can safely be relegated to the dustbin of history.

Warner