On Sun, 13 Mar 2005 14:57:49 -0500, Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Mar 13, 2005, at 14:45, Tom Keiser wrote: > > atomic_increment(&approx_invocations); > > Err, IIRC, atomic_increment automatically implies an extra > read_barrier() > and write_barrier(), no? From discussions on the LKML, I think atomic > operations are more expensive than spinlocks on many architectures, and > then you're back to the high overhead again. In any case, adding extra > read_barriers() right after the first one does not linearly add > overhead, > most of the overhead is in the cache-flushing and queue-disruption > effects of the first barrier. >
yep. we could optimize it by making the invocation counters thread-specific, but leaving the is_ok var global. assuming is_ok doesn't share a cache line with things that change frequently, that wouldn't be much of a problem... -- Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
