Date: Tue, 4 Jun 2013 00:08:47 -0400 From: Patrick Kelsey <kelsey@ieee.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Juli Mallett <jmallett@freebsd.org>, Ed Schouten <ed@80386.nl>, "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org>, FreeBSD-arch <freebsd-arch@freebsd.org> Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <CAD44qMUUQ6_FDiTknK1rcW=rs7Mz96X35QgnRxH%2Br5=ZqGRbAw@mail.gmail.com> In-Reply-To: <CAJ-Vmo=5%2BmWk4EWBuTdpF6vKx-%2BK=g1euJvZuRDF%2BvFkJNZZ4A@mail.gmail.com> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <D02AF210-5129-40AB-9481-3F0A44575E98@bsdimp.com> <CAJ-Vmo=vNbT9majPCZ8ugzPsNzh46DTD4mMDX-cuxx9Og91ptw@mail.gmail.com> <CACVs6=_X5vOfR%2BQOgvz6P-j3jUoNoK9hCFvz80fGRL3-PgBf5g@mail.gmail.com> <CAJ-Vmo=5%2BmWk4EWBuTdpF6vKx-%2BK=g1euJvZuRDF%2BvFkJNZZ4A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 3, 2013 at 11:57 PM, Adrian Chadd <adrian@freebsd.org> wrote: > On 3 June 2013 20:55, Juli Mallett <jmallett@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? > >> 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. > >> 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. > The sync + 8 nops is coming from the definition of mips_sync() in sys/mips/include/atomic.h. I agree with Juli that it appears to be a manual pipeline-flush holdover from earlier days - I'm guessing there's 8 nops because the R4000/4400 had both the sync instruction and an 8-stage pipeline. I'm further guessing this was an attempt at providing stronger ordering semantics than the sync instruction itself for the following mb()/wmb()/rmb() definitions that use it, as the sync instruction definition doesn't restrict execution of the before/after loads/stores with respect to the sync instruction itself.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMUUQ6_FDiTknK1rcW=rs7Mz96X35QgnRxH%2Br5=ZqGRbAw>