Date: Thu, 03 Jan 2002 12:57:29 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bernd Walter <ticso@cicely9.cicely.de> Cc: Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Bernd Walter <ticso@cicely8.cicely.de>, Mike Smith <msmith@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Michal Mertl <mime@traveller.cz>, Peter Jeremy <peter.jeremy@alcatel.com.au> Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <3C34C5B9.F73A224@mindspring.com> References: <XFMail.020102152920.jhb@FreeBSD.org> <200201030002.g0302Eo60575@apollo.backplane.com> <20020103003214.GC53199@cicely9.cicely.de> <3C33D580.50B5BCAA@mindspring.com> <20020103095433.GI53199@cicely9.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C34C5B9.F73A224>