[OpenAFS-devel] fileserver profiling

[Troy Benjegerdes]

On Wed, Mar 02, 2005 at 10:55:09AM -0500, Tom Keiser wrote:
> I've been profiling the pthreaded fileserver for a while now, and one
> thing continues to bother me.  We call the time() syscall so
> frequently that it's often 20% of our total execution time.
> There are plenty of hacks to reduce this overhead, but every one I
> know of will introduce some amount of non-determinism.  Is that an
> acceptable risk?
> 
> Having a thread in a nanosleep; gettimeofday loop might be acceptable,
> but during periods of high load, you couldn't guarantee that your
> global epoch time variable would be _monotonically_ increasing.  I
> suppose a combination of a SIGALRM handler and gettimeofday; setitimer
> might mitigate that problem to some extent.  Anyone have any better
> suggestions on how to reduce this overhead?

I don't see how you'd ever get a clock that goes backwards with this
method.. it might not increase under high load, but would that be a
problem?

Can we set the "time" thread to real-time priority? Or can we set up a
small chunk (say 4k) of System-V shared memory (or mmap-ed file) that 
can be updated at some configurable rate (1hz to 100hz maybe) by a process 
with real-time priority? All the AFS processes (not just the fileserver)
would then map that memory read-only.