Date: Sun, 6 Jul 2003 17:49:51 -0700 From: David Schultz <das@FreeBSD.ORG> To: Chuck Swiger <cswiger@mac.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Weird vmstat -s stats Message-ID: <20030707004951.GB26820@HAL9000.homeunix.com> In-Reply-To: <20030706213540.GU430@gsmx07.alcatel.com.au> References: <200307051728.24681.me@farid-hajji.de> <44brw8g26e.fsf@be-well.ilk.org> <200307060029.00866.me@farid-hajji.de> <3F07576F.4030105@mac.com> <20030706213540.GU430@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 07, 2003, Peter Jeremy wrote: > On 2003-Jul-05 18:55:43 -0400, Chuck Swiger <cswiger@mac.com> wrote: > >Farid Hajji wrote: > >[ ... ] > >>Shouldn't such counters be at least 64 bit wide? > > > >You betcha. :-) The problem is that a 32-bit CPU, like the Intel x86 > >family, can't increment a 64-bit counter atomicly. > > This isn't absolutely true. You _can_ perform atomic 64-bit > operations on an x86 (for x>=5), they are just extremely expensive. > > There are regular threads on this sort of problem and I don't believe > anyone has come up with a solution that did not involve overheads that > were considered unacceptable in the general case. The overhead of a 64-bit atomic increment isn't so bad on x86. It takes just a few instructions to do the arithmetic (since namei only needs to do increments), plus a cmpxchg8b. But at the moment, we actually use non-atomic increments, which appears to be a bug. We should probably just eat the overhead of 64-bit atomically-incremented counters; the cache_lookup() path isn't so critical that we need every cycle.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030707004951.GB26820>