From owner-freebsd-mips@FreeBSD.ORG Tue Jun 4 04:32:04 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F6927FD for ; Tue, 4 Jun 2013 04:32:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id F28B41A05 for ; Tue, 4 Jun 2013 04:32:03 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so11178131ied.0 for ; Mon, 03 Jun 2013 21:32:03 -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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=0sGsWd94t071+T76PYAZNXbdQAwu+/CjisI7Kru0qj4=; b=hoYAl4LIVsNR+nabzh4HxAZHV+DMa2speYh1xY23ISnufEJcwwyRS2sU6c8bTPfmvr PoH3NR4j6FBc/IH/gaTUOFUfWeHy6Q+2t7H7O7qocD6CvQOR6epmwPyPh0LrYY7k1w1R GmAcZD+II6TG95uNsj+xC20pvTjKD/SOcWEb2nveV63E71YDhY/TmrOFD36o3uKEWvI0 NievA2WZJqlNKzvYtZGEtoRt/KtcCivKN0ztBunV8Tnq9Gt/+t9G9g8wlc0meEomF7WW oHYFiaCuXl22JXTPoGLmHX/JNNWu7kxGjJl6O/0N+Zaya5zK9EfkBO4BuUazCdU/UMsj TkCg== X-Received: by 10.50.73.226 with SMTP id o2mr672932igv.22.1370320323385; Mon, 03 Jun 2013 21:32:03 -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 ot10sm16729268igb.9.2013.06.03.21.32.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 21:32:02 -0700 (PDT) Sender: Warner Losh Subject: Re: Kernelspace C11 atomics for MIPS Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 3 Jun 2013 22:32:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkS85D3GOiLZuypQgooaiYO7hoIjs6xRtdDogBGaDRMQbUORG9QQklg3fap7sktwXV2I+ge 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 04:32:04 -0000 On Jun 3, 2013, at 10:04 PM, Juli Mallett wrote: > On Mon, Jun 3, 2013 at 8: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 > 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=