From owner-svn-src-all@freebsd.org Sat Jul 25 18:03:55 2015 Return-Path: Delivered-To: svn-src-all@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 5FE589AB7CB; Sat, 25 Jul 2015 18:03:55 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39194819; Sat, 25 Jul 2015 18:03:54 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.15.0.59/8.15.0.59) with SMTP id t6PI3pSC003379; Sat, 25 Jul 2015 13:03:51 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1vv49f8688-1; Sat, 25 Jul 2015 13:03:51 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.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 mh3.mail.rice.edu (Postfix) with ESMTPSA id 44F7D4003F; Sat, 25 Jul 2015 13:03:51 -0500 (CDT) Message-ID: <55B3CF86.200@rice.edu> Date: Sat, 25 Jul 2015 13:03:50 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John-Mark Gurney , 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 References: <201507241943.t6OJhJaq090500@repo.freebsd.org> <20150724211532.GO78154@funkthat.com> In-Reply-To: <20150724211532.GO78154@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507250230 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 18:03:55 -0000 On 07/24/2015 16:15, John-Mark Gurney wrote: > 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_*() funct= ions >> with acquire and release semantics versus the *mb() functions on amd= 64 >> 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? While the first sentence is not amd64 specific, the core of this paragraph, the third, four, and fifth sentences, is very amd64 specific. In particular, the redundancy of the rmb() and wmb() functions for ordinary cases of interprocessor memory ordering is not generally true across architectures that we support. For example, on arm64 or powerpc, these functions do provide non-redundant ordering. But, I do agree that the first sentence also belongs in a man page, like atomic(9). Today, however, we have no man page documenting the *mb() functions. >> Modified: >> head/sys/amd64/include/atomic.h >> >> Modified: head/sys/amd64/include/atomic.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> --- 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 >> =20 >> +/* >> + * To express interprocessor (as opposed to processor and device) mem= ory >> + * ordering constraints, use the atomic_*() functions with acquire an= d release >> + * semantics rather than the *mb() functions. An architecture's memo= ry >> + * 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 regio= ns >> + * 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= =2E >> + * Therefore, except for special cases, like non-temporal memory acce= sses or >> + * memory regions defined as write combining, the memory ordering eff= ects >> + * provided by the sfence instruction in the wmb() function and the l= fence >> + * instruction in the rmb() function are redundant. In contrast, the= >> + * atomic_*() functions with acquire and release semantics do not per= form >> + * 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")