[OpenAFS-devel] fileserver profiling

[Tom Keiser]

On Sun, 13 Mar 2005 14:57:49 -0500, Kyle Moffett <mrmacman_g4@mac.com> 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