From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 15:00:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78EE016A420 for ; Fri, 14 Oct 2005 15:00:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5CB943D5A for ; Fri, 14 Oct 2005 15:00:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9EEv6ij089763; Fri, 14 Oct 2005 08:57:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 14 Oct 2005 08:58:16 -0600 (MDT) Message-Id: <20051014.085816.104604949.imp@bsdimp.com> To: B.Candler@pobox.com From: "M. Warner Losh" In-Reply-To: <20051014091004.GC18513@uk.tiscali.com> References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 14 Oct 2005 08:57:27 -0600 (MDT) Cc: max@love2party.net, freebsd-current@freebsd.org, anderson@centtech.com Subject: Re: ufsstat - testers / feedback wanted! 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, 14 Oct 2005 15:00:55 -0000 In message: <20051014091004.GC18513@uk.tiscali.com> Brian Candler writes: : On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: : > > I don't think you can measure one single interger (or 64bit) increase in face : > > of a operation that has to access backing store. Even if there is a : > > performance hit, you don't have to build your kernel with the option enabled. : > : > The one thing I'd be worried about here is that 64bit updates are : > expensive on 32bit machines if you want them to be atomic. Relative to : > backing store they probably still don't matter, but the might be : > noticable. : : I'd be grateful if you could clarify that point for me. Are you saying that : if I write : : long long foo; : ... : foo++; : : then the C compiler generates code for 'foo++' which is not thread-safe? : (And therefore I would have to protect it with a mutex or critical section) : : Or are you saying that the C compiler inserts its own code around foo++ to : turn it into a critical section, and therefore runs less efficiently than : you'd expect? You have to protect this thread-unsafe operation yourself. Warner