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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
