From owner-svn-src-head@freebsd.org Fri Jul 24 21:15:39 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A2C59AA11C; Fri, 24 Jul 2015 21:15:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D19321C65; Fri, 24 Jul 2015 21:15:38 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t6OLFWAU095282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 14:15:32 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t6OLFWo1095281; Fri, 24 Jul 2015 14:15:32 -0700 (PDT) (envelope-from jmg) Date: Fri, 24 Jul 2015 14:15:32 -0700 From: John-Mark Gurney To: Alan Cox Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285854 - head/sys/amd64/include Message-ID: <20150724211532.GO78154@funkthat.com> References: <201507241943.t6OJhJaq090500@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201507241943.t6OJhJaq090500@repo.freebsd.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 24 Jul 2015 14:15:32 -0700 (PDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 21:15:39 -0000 Alan Cox wrote this message on Fri, Jul 24, 2015 at 19:43 +0000: > Author: alc > Date: Fri Jul 24 19:43:18 2015 > New Revision: 285854 > URL: https://svnweb.freebsd.org/changeset/base/285854 > > Log: > Add a comment discussing the appropriate use of the atomic_*() functions > with acquire and release semantics versus the *mb() functions on amd64 > processors. Please put this documentation in the atomic(9) man page where it is easier to read and access... it's probably best to just move it there and reference atomic(9) here... Also, this advice isn't amd64 specific is it? If it isn't, why is it in an amd64 include file? > Modified: > head/sys/amd64/include/atomic.h > > Modified: head/sys/amd64/include/atomic.h > ============================================================================== > --- head/sys/amd64/include/atomic.h Fri Jul 24 19:37:30 2015 (r285853) > +++ head/sys/amd64/include/atomic.h Fri Jul 24 19:43:18 2015 (r285854) > @@ -32,6 +32,25 @@ > #error this file needs sys/cdefs.h as a prerequisite > #endif > > +/* > + * To express interprocessor (as opposed to processor and device) memory > + * ordering constraints, use the atomic_*() functions with acquire and release > + * semantics rather than the *mb() functions. An architecture's memory > + * ordering (or memory consistency) model governs the order in which a > + * program's accesses to different locations may be performed by an > + * implementation of that architecture. In general, for memory regions > + * defined as writeback cacheable, the memory ordering implemented by amd64 > + * processors preserves the program ordering of a load followed by a load, a > + * load followed by a store, and a store followed by a store. Only a store > + * followed by a load to a different memory location may be reordered. > + * Therefore, except for special cases, like non-temporal memory accesses or > + * memory regions defined as write combining, the memory ordering effects > + * provided by the sfence instruction in the wmb() function and the lfence > + * instruction in the rmb() function are redundant. In contrast, the > + * atomic_*() functions with acquire and release semantics do not perform > + * redundant instructions for ordinary cases of interprocessor memory > + * ordering on any architecture. > + */ > #define mb() __asm __volatile("mfence;" : : : "memory") > #define wmb() __asm __volatile("sfence;" : : : "memory") > #define rmb() __asm __volatile("lfence;" : : : "memory") -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."