From owner-svn-src-head@freebsd.org Sat Jul 25 19:31:12 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 B46DA9AA385; Sat, 25 Jul 2015 19:31:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0E71081; Sat, 25 Jul 2015 19:31:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 47AD21A07D8; Sun, 26 Jul 2015 05:31:03 +1000 (AEST) Date: Sun, 26 Jul 2015 05:31:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alan Cox cc: John-Mark Gurney , Alan Cox , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285854 - head/sys/amd64/include In-Reply-To: <55B3CF86.200@rice.edu> Message-ID: <20150726051421.C892@besplex.bde.org> References: <201507241943.t6OJhJaq090500@repo.freebsd.org> <20150724211532.GO78154@funkthat.com> <55B3CF86.200@rice.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ItbjC+Lg c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=jOycMddxPMzTkANAw7kA:9 a=CjuIK1q_8ugA:10 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: Sat, 25 Jul 2015 19:31:12 -0000 On Sat, 25 Jul 2015, Alan Cox wrote: > On 07/24/2015 16:15, John-Mark Gurney wrote: >> Alan Cox wrote this message on Fri, Jul 24, 2015 at 19:43 +0000: >>> ... >>> 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... Your "." key is still sticky. >> 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. It all applies to i386. Literally after s/amd64/x86/g. > 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. These functions are documented in atomic(9) by their absence. Since they are undocumented, they don't exist :-). The man page is also deficient and wrong about the MD set of types available. It says that the 64 bit type is [always] available, but it is unavailable on most or all 32-bit arches for most or all operations. It says that the set of available smaller types is MD but the only way to find the set is to read the source code. The small types are just bloat, since they are unusable in MI code and never used in MD code for at least amd64 and i386. *mb() is similar. It acts in an undocumented MD way, so it is unusable in MI code. Bruce