Date: Mon, 3 Jun 2013 22:32:00 -0600 From: Warner Losh <imp@bsdimp.com> To: Juli Mallett <jmallett@FreeBSD.org> Cc: Ed Schouten <ed@80386.nl>, Adrian Chadd <adrian@freebsd.org>, "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org>, FreeBSD-arch <freebsd-arch@freebsd.org> Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <A587E5ED-3AF6-4F94-9BDE-78A84B1A9112@bsdimp.com> In-Reply-To: <CACVs6=9pgL57vY4SLXZekGv7kRP515sRuL-K7eS0QwgSUoN1ZA@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> <CACVs6=9pgL57vY4SLXZekGv7kRP515sRuL-K7eS0QwgSUoN1ZA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 3, 2013, at 10:04 PM, Juli Mallett wrote: > On Mon, Jun 3, 2013 at 8:57 PM, Adrian Chadd <adrian@freebsd.org> = wrote: > On 3 June 2013 20:55, Juli Mallett <jmallett@freebsd.org> wrote: >=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 > How can I turn it off for my compiles? >=20 > 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. =46rom 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.) >=20 > Right. Well, since it's happening on every inlined lock, it's a bit = silly. >=20 > 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. >=20 > I've checked the diassembly from gcc-4.mumble on linux; it doesn't > include NOPs like this as far as I can tell. >=20 > Neat. >=20 > 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. =20 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A587E5ED-3AF6-4F94-9BDE-78A84B1A9112>