From owner-freebsd-current@FreeBSD.ORG Fri Apr 13 07:35:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4876C16A408; Fri, 13 Apr 2007 07:35:01 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id D2B8613C44C; Fri, 13 Apr 2007 07:35:00 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id BA28310D312; Fri, 13 Apr 2007 17:34:53 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C9B2B8C16; Fri, 13 Apr 2007 17:34:57 +1000 (EST) Date: Fri, 13 Apr 2007 17:34:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86slb5e33a.fsf@dwp.des.no> Message-ID: <20070413164840.V31079@besplex.bde.org> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-579877781-1176449696=:31079" X-Mailman-Approved-At: Fri, 13 Apr 2007 11:28:39 +0000 Cc: freebsd-fs@freebsd.org, Craig Boston , "Rick C. Petty" , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 07:35:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-579877781-1176449696=:31079 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 12 Apr 2007, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Craig Boston writes: >> On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote: >>> Is there any way we could make the choice at boot time, by checking for >>> presence of the CX8 feature? Either as something like: >>> >>> extern int feature_cx8;=09=09/* or MIB variable */ >>> #define CMPXCHG8(a)=09(feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a= )) >> For something this low level my opinion is it's better to stay with >> compile time options. After all, in the above example, cmpxchg8 is a >> single machine instruction. How much overhead does it add to retrieve a >> variable from memory and check it, then jump to the correct place? >> Enough that it outweighs the benefit of using that instruction in the >> first place? Not for cmpxchg8b, at least. It is a remarkably slow instruction. On AthlonXP's it has an execution latency of 39 cycles. cmpxchg only has an cmpxchg only has an execution latency of 6 cycles (both without a lock prefix). I don't know how to avoid using cmpxchg8b short of using a mutex lock/unlock pair and slightly different semantics, or a generation count and very different semantics, but without lock prefixes the mutex pair would be much faster than the cmpxchg8b. > I don't think it matters. I agree. > Contrary to popular belief, atomic > operations are *expensive*. Doesn't everyone who uses atomic operations knows that they are expensive? = :) > In the best case, on a UP machine, they > stall the pipeline. In the worst case, on an SMP machine, they stall > the entire memory bus. In the UP case, the pipeline stall is tiny or null. Independent instructions can still proceed, but CPUs (that have pipelines) usually can't keep pipelines moving anyway, and atomic instructions just reduce the chance that they can a little. Bruce --0-579877781-1176449696=:31079--