From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 18:52:03 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2FA916A402; Thu, 12 Apr 2007 18:52:03 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id C882613C48C; Thu, 12 Apr 2007 18:52:01 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 7DAB6110A3; Thu, 12 Apr 2007 13:52:01 -0500 (CDT) Date: Thu, 12 Apr 2007 13:51:59 -0500 From: Craig Boston To: "Rick C. Petty" Message-ID: <20070412185159.GB95302@nowhere> Mail-Followup-To: Craig Boston , "Rick C. Petty" , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412160603.GB92079@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 18:52:04 -0000 On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote: > On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm?rgrav wrote: > > > > Our native atomic operations are all defined as either macros or > > static inline functions in machine/atomic.h, so we can easily make > > this choice at compile time based on a config option. > > 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; /* or MIB variable */ > #define CMPXCHG8(a) (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? For entire functions that have been optimized (bzero comes to mind) you can always either use a function pointer or overwrite the code in memory with the optimized version. The function call overhead presumably isn't that much compared to the work that the function is doing. > Otherwise something like ZFS which utilizes this feature a lot could > check the MIB variable and set different fn ptr in its device structure, > or something along those lines. Of course, that would require compiling > the same code twice essentially, but it had the advantage that it would > work on non-CX8 systems and that it would be fast on systems with CX8. I agree this makes sense for some things, but atomic operations are supposed to be as fast as possible -- preferably single machine instructions I can't think of anything short of JIT compiling the kernel that wouldn't be a high price to pay. Craig