From owner-svn-src-head@FreeBSD.ORG Fri Jun 18 01:57:47 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 95835106566C; Fri, 18 Jun 2010 01:57:47 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4DFE48FC08; Fri, 18 Jun 2010 01:57:47 +0000 (UTC) Received: from lawrence1.loshell.room52.net (unknown [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id C2C267E84A; Fri, 18 Jun 2010 11:57:38 +1000 (EST) Message-ID: <4C1AD292.5070508@freebsd.org> Date: Fri, 18 Jun 2010 11:57:38 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.1.9) Gecko/20100405 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20100617071300.GX13238@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Matthew Fleming , src-committers@freebsd.org, Pawel Jakub Dawidek , John Baldwin , svn-src-all@freebsd.org, brde@optusnet.com.au, svn-src-head@freebsd.org 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 01:57:47 -0000 On 06/17/10 17:13, Kostik Belousov wrote: > On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote: >> On 06/14/10 20:43, Kostik Belousov wrote: [snip] >>> Or, you could ditch the sum at all, indeed using ({}) and returning the >>> result. __typeof is your friend to select proper type of accumulator. >> >> So, something like this? >> >> #define DPCPU_SUM(n, var) __extension__ \ >> ({ \ >> u_int _i; \ >> __typeof((DPCPU_PTR(n))->var) sum; \ >> \ >> sum = 0; \ >> CPU_FOREACH(_i) { \ >> sum += (DPCPU_ID_PTR(_i, n))->var; \ >> } \ >> sum; \ >> }) >> >> Which can be used like this: >> >> totalss.n_in = DPCPU_SUM(ss, n_in); > Yes, exactly. > >> >> >> I've tested the above and it works. I also prefer the idea of having >> DPCPU_SUM return the sum so that you can do "var = DPCPU_SUM(...)". My >> only concern with this method is that the caller no longer has the >> choice to make the sum variable a larger type to avoid overflow. It >> would be nice to be able to have the DPCPU vars be uint32_t but be able >> to sum them into a uint64_t accumulator for example. Perhaps this isn't >> really an issue though... I'm not sure. > You are worried about overflow in the sum of 32 or 64 variables, but if > this is the case, then each member of the sum can overflow as well, IMO. > Either ignore the issue, or use a uintmax_t. 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. Cheers, Lawrence