Date: Mon, 3 Jun 2013 21:04:57 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: 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: <CACVs6=9pgL57vY4SLXZekGv7kRP515sRuL-K7eS0QwgSUoN1ZA@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 8: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? 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. > > 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. > > 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. 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. Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=9pgL57vY4SLXZekGv7kRP515sRuL-K7eS0QwgSUoN1ZA>