From owner-freebsd-arch Thu Jan 3 12:57:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 1693D37B41B; Thu, 3 Jan 2002 12:57:34 -0800 (PST) Received: from pool0238.cvx40-bradley.dialup.earthlink.net ([216.244.42.238] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16MEvY-000292-00; Thu, 03 Jan 2002 12:57:28 -0800 Message-ID: <3C34C5B9.F73A224@mindspring.com> Date: Thu, 03 Jan 2002 12:57:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernd Walter Cc: Matthew Dillon , John Baldwin , arch@FreeBSD.ORG, Bernd Walter , Mike Smith , Bruce Evans , Michal Mertl , Peter Jeremy Subject: Re: When to use atomic_ functions? (was: 64 bit counters) References: <200201030002.g0302Eo60575@apollo.backplane.com> <20020103003214.GC53199@cicely9.cicely.de> <3C33D580.50B5BCAA@mindspring.com> <20020103095433.GI53199@cicely9.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > > Unless there are two sounts that MUST remain synchornized for > > correct operation, you don't *care* if someone gets the stale > > value. > > > > Ask yourself: what's the worst case failure scenario that would > > result? > > If I ask a value I may get a recent value x. > If I ask with another CPU later I may get an older value than x. > > Having slightly out of date statistisks isn't a problem, but > statistiks getting backwards definately are. You've added an implied constraint: that the values must be monotonically increasing when examined at two different times between two different CPUs. I'd say your statistics should be stored in a non-cacheable page. This is sure to make you popular. 8-). Really, what matters is *what are you using them for?*; this is what will dictate the properties they need to have; perhaps the property you think they need is not really the property they need? The place where I see this being an issue, for example, is in the interrupt counts by interrupt. I would argue that these counts should be kept by card instance by driver, and not by interrupt, anyway. Be redefining the problem, we end up with a statistic that does not have the problems you cite. If someone needs a "by interrupt" statistic, then it can be obtained at the time it is requested, rather than maintained as a strict count on its own. Thus the penalty of the count synchronization overhead is only taken when such a count is requested, rather than "at all times", by summing the count of the driver instances attached to the intterupt(s) in question. I would argue that "vmstat -i" is a very rare occurance, as far as system events go, and its means of keeping statistics are actually obfuscating which card is causing the interrupt, and that you get *better* statistics by keeping them on a per card basis than on a per intterupt basis, so it's a net win to keep the statistics a different way. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message