[OpenAFS-devel] fileserver profiling

[Troy Benjegerdes]

> >Also, due to the very coarse-grained nature of barriers on most
> >architectures, we wouldn't know, without substantial profiling, how
> >large of an impact this would have on things like instruction-level
> >parallelism and out-of-order execution.
> 
> It's significantly better than a whole syscall with instruction cache 
> killing
> on _all_ platforms, except for a very few that do gettimeofday in a 
> vDSO.
> 

[snip]

> >In reality, this mmap'd file concept would work a lot better if it
> >were handled just like the new /dev/poll interface.  The scheduler
> >could simply write the new epoch time into a page every second, and
> >there could just be a character device you could mmap to get the time
> >without trapping into kernel mode.  But, that's a discussion for
> >another list...
> 
> Linux has a couple archs working on vDSOs that implement gettimeofday
> completely in userspace without
> 
> Cheers,
> Kyle Moffett

The vDSO implementations of gettimeofday() use the cycle counters (at
least on PPC). So as long as the cycle counters on all cpus are synched,
there's no syscall or cache thrashing.

I think the discussion we care about here is that with the previously
suggested program, we could switch all of the openafs code to use either
gettimeofday() on arches with the vDSO implementations, or use the above
program as a portable alternative.

I'd also argue that the update frequency should be something closer to
100hz or 1000hz. This would be usefull on all these new multi-core
and/or hyperthreading CPU's IBM, Intel, and AMD are all talking about
these days.

What is the finest time granualarity we need in OpenAFS anyway?