From owner-freebsd-mips@FreeBSD.ORG Tue Jun 4 18:07:12 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 F20E229D; Tue, 4 Jun 2013 18:07:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4681210; Tue, 4 Jun 2013 18:07:11 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id q19so409787qeb.4 for ; Tue, 04 Jun 2013 11:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ye+/DK9B8RSq2OPcPcACrpKg94AVyIf7MLo8RohwV+U=; b=TuaeoYMffceTzPIq49hkvisUPY+x9S1kLU+YaiuOCEejtxHYz4bvlV01iecsIwfz+c Qa5wxXbAcyvpzt1i1Kf4UZtID5H7NYPM7Bl06C6IFYpnIgi5GWn3ivFYkq/0K3MPuyW/ a24xwmS4kqa2DBhSaNzKGxmN+3Zz65Oj5bxDxA7CWJBbqC8K1hOG3uRBBlh/z1Scf998 b4MXneK7Pq/9lQXyGJ/EJGlXvD5KJbn0MsF+C3Y4S2fO/iMgtusCBqgXk6kDiCCWAquY VEvFc8n8PI3bo8mZyW8X7yncW81MEAQRhQYyt5Xm1LHQRxcSrugsH15rzI6UStpNJ1H7 oUOA== MIME-Version: 1.0 X-Received: by 10.229.149.14 with SMTP id r14mr6819349qcv.59.1370369225122; Tue, 04 Jun 2013 11:07:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.71.12 with HTTP; Tue, 4 Jun 2013 11:07:05 -0700 (PDT) In-Reply-To: <232DBBD8-3F32-4D42-85AB-AC5647EEA768@bsdimp.com> References: <232DBBD8-3F32-4D42-85AB-AC5647EEA768@bsdimp.com> Date: Tue, 4 Jun 2013 11:07:05 -0700 X-Google-Sender-Auth: VI61RTyvzr8ndvlahzEoCAnACaw Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-arch , "freebsd-mips@FreeBSD.org" , Ed Schouten 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 18:07:12 -0000 Hi, It survived an overnight thrashing on my AR7161 (mips24k.) Adrian On 3 June 2013 22:07, Warner Losh wrote: > Please find attached a simple patch that I'd like all MIPS users to try. > > Warner > > > > > 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: >>>> >>>>> 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? >>>> >>>>> 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. >>>> >>>>> 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. >>>> >>> >>> The sync + 8 nops is coming from the definition of mips_sync() in >>> sys/mips/include/atomic.h. >>> >>> 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. >> >> 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" > >