From owner-svn-src-head@FreeBSD.ORG Fri Jun 18 12:08:56 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5ED81065672; Fri, 18 Jun 2010 12:08:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8D8D8FC0C; Fri, 18 Jun 2010 12:08:56 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2D36746C5B; Fri, 18 Jun 2010 08:08:56 -0400 (EDT) Date: Fri, 18 Jun 2010 13:08:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lawrence Stewart In-Reply-To: <4C1AD292.5070508@freebsd.org> Message-ID: References: <201006130239.o5D2du3m086332@svn.freebsd.org> <20100613101025.GD1320@garage.freebsd.pl> <4C158B71.205@freebsd.org> <20100614085205.GD13238@deviant.kiev.zoral.com.ua> <4C1605A7.2000202@freebsd.org> <20100614104349.GF13238@deviant.kiev.zoral.com.ua> <4C198A90.3060905@freebsd.org> <20100617071300.GX13238@deviant.kiev.zoral.com.ua> <4C1AD292.5070508@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Matthew Fleming , src-committers@freebsd.org, Pawel Jakub Dawidek , John Baldwin , svn-src-all@freebsd.org, svn-src-head@freebsd.org, brde@optusnet.com.au, Kostik Belousov Subject: Re: svn commit: r209119 - head/sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 18 Jun 2010 12:08:56 -0000 On Fri, 18 Jun 2010, Lawrence Stewart wrote: > True but I figured on large SMP systems where the potential to process more > is likely, 32bit counters per cpu may be enough to avoid overflow but the > aggregate number of events may exceed a 32bit variable. I suspect you're > right though and that if there's a likely chance the aggregate could > overflow, then the DPCPU var should simply be made 64bit to also remove any > possibility of individual PCPU counters overflowing. > > I'll commit the above version of the macro this evening (GMT+10) unless I > hear any objections. Thanks to all of you for your input. The only reservation I have, really, is that 64-bit writes are non-atomic on i386 and other 32-bit architectures (or, at least, I think they are). This means DPCPU_SUM may encounter non-atomicity rather than just staleness in the values it reads as it iterates. That said, we should probably use 64-bit anyway, because 32-bit counters are gauche. :-) Robert