[OpenAFS-devel] fileserver profiling

[Troy Benjegerdes]

On Thu, Mar 03, 2005 at 08:08:27PM -0500, Derrick J Brashear wrote:
> On Thu, 3 Mar 2005, Troy Benjegerdes wrote:
> 
> >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?
> 
> We have had a multiprocessor Linux system where the clock went backwards 
> without the help of ntp during normal operation.

How many CPU's did this system have, and what version of Linux? If this
is still reproduceable on a 2.4 or 2.6 kernel, it should be fixed.
(Also, was this x86, or some other architecture)
 
> >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.
> 
> sysv shared memory will have portability issues. mmap() is probably 
> better. but lwp dealt by having an approxtime and a time call, and if you 
> needed a real time, you asked, and if you didn't you used the cached time.
> e.g. we already had a hack.

If we have some process updating the time in a mmap()'ed file, wouldn't that
have about the same cost as getting a cached time? If we are paranoid
about time going backwards, the process updating the time could check
for that as well, and spit out some verbose warning to syslog.