On Mon, Jul 07, 2003, Peter Jeremy wrote: > On 2003-Jul-05 18:55:43 -0400, Chuck Swiger <[EMAIL PROTECTED]> 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. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
