From owner-svn-src-all@FreeBSD.ORG Sat Jun 19 03:29:53 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5BA1065670; Sat, 19 Jun 2010 03:29:53 +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 B3BCC8FC15; Sat, 19 Jun 2010 03:29:52 +0000 (UTC) Received: from lawrence1.loshell.room52.net (unknown [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id DA09E7E84A; Sat, 19 Jun 2010 13:29:51 +1000 (EST) Message-ID: <4C1C39AF.5010906@freebsd.org> Date: Sat, 19 Jun 2010 13:29:51 +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: Robert Watson 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> In-Reply-To: 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, svn-src-head@FreeBSD.org, brde@optusnet.com.au, Kostik Belousov Subject: Re: svn commit: r209119 - head/sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 03:29:53 -0000 On 06/18/10 22:08, Robert Watson wrote: > > 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. I've just committed the updated macro to at least get the new calling syntax settled in. > 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. :-) hrm that's messy and somewhat useless. Are there some tricks we can add to force a flush of any outstanding writes to the DPCPU var on the cpu we're reading from to ensure the counter is at least stable at the time we read? This stuff is way beyond my realm of knowledge so I defer to the greater wisdom of the masses on this. Cheers, Lawrence