[OpenAFS-devel] fileserver profiling

[Kyle Moffett]

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.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------