Date: Wed, 26 Dec 2001 12:21:37 -0800 From: Mike Smith <msmith@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org Subject: Re: 64 bit counters Message-ID: <200112262021.fBQKLbM01442@mass.dis.org> In-Reply-To: Your message of "Wed, 26 Dec 2001 13:59:02 CST." <20011226135902.O91594@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> One solution is to implement it correctly then add a knob to
> turn off the syncronization for those that want speed over
> correctness. They can poison their data if they so desire.
This isn't good either; if you give someone a knob that can be switched
from "works" to "does not work", then someone is going to set it to "does
not work" and then complain.
Better would be to architect a solution that works universally. You can
do this with 32-bit 'working' counters which you access atomically, and
maintain a 64-bit global counter that's only updated under a lock:
u_int32_t wcounter
u_int64_t ggounter
lock_t gc_lock
u_int32_t x;
acquire_lock(gc_lock)
x = atomic_fetch_32(wcounter)
atomic_subtract_32(wcounter, x)
gcounter += x
release_lock(gc_lock)
Do this on a periodic basis, with the interval tuned so that stats update
"often enough" but without imposing too much lock load.
If atomic ops on the working counters are too expensive on SMP systems,
you can keep per-CPU working counters. Reaping them becomes somewhat
more expensive (since you have one reap per CPU per interval) however.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
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?200112262021.fBQKLbM01442>