From owner-freebsd-arch@FreeBSD.ORG Tue Jun 4 04:05:25 2013 Return-Path: Delivered-To: freebsd-arch@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 01E79384 for ; Tue, 4 Jun 2013 04:05:25 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7C454194F for ; Tue, 4 Jun 2013 04:05:24 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id w10so180322lbi.9 for ; Mon, 03 Jun 2013 21:05:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=WVG2tjYb43vhRNx/JWGJd6FCPwewo2DPNIzuj6sE36g=; b=dteRKqoni8tKMfTn+bZcdKmEZCDZPQJVVVF6IQuRFzdbv8/u4ifKSZRIMmJJ5sawNJ YRWd6mqt0xeXxNgBbHQT5h0zvUso4AYWyePRHNkPTB4yOmgnPCJNfW55isxrIETMN/r2 uiFfIx1dVMaDmy/JWlaK/09UKTPwNt2NbGvCoXKAhSsLuOUPmOUA1TloAAS9GM++ASA6 o/QnVzndC2+FiXiaJO3EXak6CkxybzCEyfb41HRhXuza0A7NEFfaQXAzdSX1PmyatVXE pAWNm74pLP/N4PdxPgk7CyoivTlp9vj75OAN5xGgSs8K1eB5hOoo8BH0136+nikpPAUy lQsg== X-Received: by 10.112.180.232 with SMTP id dr8mr12138264lbc.67.1370318717158; Mon, 03 Jun 2013 21:05:17 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.195 with HTTP; Mon, 3 Jun 2013 21:04:57 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Mon, 3 Jun 2013 21:04:57 -0700 X-Google-Sender-Auth: XobjzOOSHy3MIjEHOo-pP8uINW0 Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS To: Adrian Chadd X-Gm-Message-State: ALoCoQmFf1enXc1K5hJ6gRyMmmfGE77EpKacwaip8ykCp/RL4x00gajZKnIcdlkZo1A1dHljfR2c Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ed Schouten , "freebsd-mips@FreeBSD.org" , FreeBSD-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:05:25 -0000 On Mon, Jun 3, 2013 at 8: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? 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.