Date: Tue, 4 Jun 2013 12:22:33 +0000 From: Andrew Duane <aduane@juniper.net> To: Juli Mallett <jmallett@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Cc: 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: <477C1270D3E5484DA2303CEBE274C9E13210A1C0@CH1PRD0510MB392.namprd05.prod.outlook.com> In-Reply-To: <CACVs6=_X5vOfR%2BQOgvz6P-j3jUoNoK9hCFvz80fGRL3-PgBf5g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-mips@freebsd.org [mailto:owner-freebsd- > mips@freebsd.org] On Behalf Of Juli Mallett > Sent: Monday, June 03, 2013 11:55 PM > To: Adrian Chadd > Cc: Ed Schouten; freebsd-mips@FreeBSD.org; FreeBSD-arch > Subject: Re: Kernelspace C11 atomics for MIPS >=20 > On Mon, Jun 3, 2013 at 7:45 PM, Adrian Chadd <adrian@freebsd.org> wrote: >=20 > > 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. > > >=20 > 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. >=20 > I've certainly gotten rid of them and some other cargo cult synchronizati= on > 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.) >=20 > The trouble is that proving they aren't necessary requires being rigorous > and careful in understanding documentation and errata, and FUD about thei= r > 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 nee= ded, what kind of barrier is needed and where, and which type of NOP is nee= ded (Alpha had at least two). The barriers are designed to insure correct o= peration 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 ope= ration, 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 hardwar= e 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. >=20 > Juli. > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >=20 .................................... Andrew L. Duane Resident Architect - AT&T Technical Lead m +1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477C1270D3E5484DA2303CEBE274C9E13210A1C0>