From owner-freebsd-mips@FreeBSD.ORG Tue Jun 4 05:07:46 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85C5F74 for ; Tue, 4 Jun 2013 05:07:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 59C951B16 for ; Tue, 4 Jun 2013 05:07:46 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id md4so6689367pbc.35 for ; Mon, 03 Jun 2013 22:07:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ZT2hy3S9lWNrMxgh/knBaazXir6HH2gE2yZYYehORdo=; b=W5O23I3t1cO8GS2TJsLYHNXl1ayoGg/cakDaVK9iMjDd6/kId1Xmn7DMe34uea0AmR PWwVi1zqRfahvmfysYgRQnilCHbRpibEbcIFbVlTHX7TVSJrokBgOaB3CD9EybunNozc /2+RClFvUxHeZ1gpvsCw7KhV/moxkbSYbJGEj+ZjVnC9cNIcaRWmZgTKL1KExKf8d6lv AvE8ibzD3XwE70bi6+h7Jddn5+qwzphWh0jVvuOhCd23nYPkfUdBPfAJAZHIX5n/6ek2 cvVTD+Nqbvy8Vy3YSkzE/xe6BQU2T9c5z6oQUwyjXIJK1rXNosCDZ0jqbzwwQfP6CLOA Hoag== X-Received: by 10.68.71.129 with SMTP id v1mr27218958pbu.136.1370322465563; Mon, 03 Jun 2013 22:07:45 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b10sm14925302pag.22.2013.06.03.22.07.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 22:07:44 -0700 (PDT) Sender: Warner Losh Subject: Re: Kernelspace C11 atomics for MIPS Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary=Apple-Mail-8--974245673 From: Warner Losh In-Reply-To: Date: Mon, 3 Jun 2013 23:07:41 -0600 Message-Id: <232DBBD8-3F32-4D42-85AB-AC5647EEA768@bsdimp.com> References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn4icn/OV7ajlYFn6ON4MyEBIdb+QThNUWA5HMRL5kK5nE+SXqzvrTzGKKtE1OuSza13iSC Cc: Ed Schouten , "freebsd-mips@FreeBSD.org" , FreeBSD-arch X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 05:07:46 -0000 --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 = wrote: >> On Mon, Jun 3, 2013 at 11:57 PM, Adrian Chadd = wrote: >>> On 3 June 2013 20:55, Juli Mallett 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--