From owner-freebsd-arch@FreeBSD.ORG Thu Apr 9 08:17:11 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1426A69D; Thu, 9 Apr 2015 08:17:11 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDAB3B63; Thu, 9 Apr 2015 08:17:10 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id t398H9jx001935; Thu, 9 Apr 2015 03:17:09 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1tn8hm0ddf-1; Thu, 09 Apr 2015 03:17:08 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id CA5434C01FE; Thu, 9 Apr 2015 03:17:04 -0500 (CDT) Message-ID: <5526357D.3080403@rice.edu> Date: Thu, 09 Apr 2015 03:17:01 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-arch@freebsd.org Subject: Re: atomic ops References: <20141028025222.GA19223@dft-labs.eu> <20150409061448.GB6086@dft-labs.eu> In-Reply-To: <20150409061448.GB6086@dft-labs.eu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=2.26150542737003e-10 kscore.compositescore=0.247412313810446 circleOfTrustscore=0 compositescore=0.600409725240766 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.600409725240766 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.000409725240765767 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504090074 Cc: Attilio Rao , adrian@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 08:17:11 -0000 On 04/09/2015 01:14, Mateusz Guzik wrote: > On Tue, Oct 28, 2014 at 03:52:22AM +0100, Mateusz Guzik wrote: > [scratching old content so that I hopefully re-state it nicer] > > I would like to reviwe the discussion about memory barriers provided in= > the kernel. > > The kernel (at least on amd64) lacks lightweight barriers providing onl= y > following guarantees: > - all writes are completed prior to given point > - all reads are completed prior to given point > > On amd64 such barriers require only compiler barrier, and as such > obviously beat currently used operations like load_acq (which uses > cmpxchg). > > Example consumer which would benefit greatly from such barriers is > seq.h: > https://svnweb.freebsd.org/base/head/sys/sys/seq.h?view=3Dmarkup > > _load_acq on amd64 provides full barrier and it was noted we should not= > change that in order to not break possible 3rd party consumers. > Also I don't see any alternative naming convention trying to stick to > this scheme that we could use. > > As such I propose stealing naming from Linux and introduction of smp_wm= b > and smp_rmb macros providing aforementioned funcionality. > > So for amd64 this would be: > #define smp_wmb() __compiler_membar() > #define smp_rmb() __compiler_membar() > > Any objections? > > I'm happy to talk to arch maintainers in order to get relevant > implementations for all architectures. > How about stealing from C11's stdatomic.h instead of Linux. C11's model for expressing memory access ordering requirements is, like our atomic.h, inspired by the release consistency model. And, stdatomic.h has an operation, atomic_thread_fence(), that allows you to express the need for acquire and/or release ordering at some point in your program without an associated memory access.