Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Jun 2013 23:07:41 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Patrick Kelsey <kelsey@ieee.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:  <232DBBD8-3F32-4D42-85AB-AC5647EEA768@bsdimp.com>
In-Reply-To: <CAD44qMV2indeyD-OsJsyR_yp-HowJOrKG6Znx3zHkSKzt7xQzA@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> <CAD44qMUUQ6_FDiTknK1rcW=rs7Mz96X35QgnRxH%2Br5=ZqGRbAw@mail.gmail.com> <CAD44qMV2indeyD-OsJsyR_yp-HowJOrKG6Znx3zHkSKzt7xQzA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail-8--974245673
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Please find attached a simple patch that I'd like all MIPS users to try.

Warner


--Apple-Mail-8--974245673
Content-Disposition: attachment;
	filename=P
Content-Type: application/octet-stream;
	x-unix-mode=0664;
	name="P"
Content-Transfer-Encoding: 7bit

Index: atomic.h
===================================================================
--- atomic.h	(revision 250753)
+++ atomic.h	(working copy)
@@ -44,20 +44,16 @@
  * do not have atomic operations defined for them, but generally shouldn't
  * need atomic operations.
  */
+#ifndef __MIPS_PLATFORM_SYNC_NOPS
+#define __MIPS_PLATFORM_SYNC_NOPS ""
+#endif
 
 static __inline  void
 mips_sync(void)
 {
-	__asm __volatile (".set noreorder\n\t"
-			"sync\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
-			"nop\n\t"
+	__asm __volatile (".set noreorder\n"
+			"\tsync\n"
+			__MIPS_PLATFORM_SYNC_NOPS
 			".set reorder\n"
 			: : : "memory");
 }

--Apple-Mail-8--974245673
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



On Jun 3, 2013, at 10:15 PM, Patrick Kelsey wrote:

> On Tue, Jun 4, 2013 at 12:08 AM, Patrick Kelsey <kelsey@ieee.org> =
wrote:
>> 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:
>>>=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
>>>> 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
>>>> 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
>>=20
>> The sync + 8 nops is coming from the definition of mips_sync() in
>> sys/mips/include/atomic.h.
>>=20
>> 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.
>=20
> Forgot to emphasize that this particular bit of old-school
> nop-counting is either pointless or a latent hazard - 8 does not cover
> the deepest MIPS pipeline around, then there's superscalar issue to
> consider - so I think it's either unnecessary or insufficient.  So
> far, that's all criticism and no solution :/
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to =
"freebsd-arch-unsubscribe@freebsd.org"


--Apple-Mail-8--974245673--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?232DBBD8-3F32-4D42-85AB-AC5647EEA768>