From owner-freebsd-arch@FreeBSD.ORG Tue Jun 4 04:15:20 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68DF862D; Tue, 4 Jun 2013 04:15:20 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 710E4198F; Tue, 4 Jun 2013 04:15:19 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id ji2so1022881bkc.10 for ; Mon, 03 Jun 2013 21:15:18 -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=H1WND2Yc9hbvyisbZ6h5Xe9U6SOzd4cTJmVloti6WtU=; b=GUnkZGY18aWJ3BmoAuE6ShVUJC8El4GStrAUmMGJvkOxJQkQshhyzJrpirC8MwBKdI OK1fZ6UOvQfqDM8ArR1Vc/GhV0yqVWW1G3JeCNXjx/f6JhBAembg4s2V//1KfrC4Swr5 7XNSiZo0692hDkt54w4bRJEoekSD6g80IsuQlaNKO8MmSCpT6BG6v1AvZcpaWaudOaRC meGmU3Abrd5XyWdFNL8HKGZXuNjAzbMTDfyMomQckxwxs+FYtq86qGIh8ZyMGSCUc8WN 5StdB4LWUmt4OpndBNNh7bqowg5fetBtztj+uOrecWEvQdrQtndNhFR4MN8zNC6s+v2x 6iHA== MIME-Version: 1.0 X-Received: by 10.205.107.202 with SMTP id dz10mr7284751bkc.180.1370319317940; Mon, 03 Jun 2013 21:15:17 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.205.141.68 with HTTP; Mon, 3 Jun 2013 21:15:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 00:15:17 -0400 X-Google-Sender-Auth: GsvU6Ysz54D3_WzBTuuZdPLpqiM Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: Patrick Kelsey To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Juli Mallett , 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:15:20 -0000 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 :/