Doug Barton wrote:
> Alexander suggested some knobs to twist for the timers, and I'll be glad
> to do that once he gets back to me with more concrete suggestions now
> that he knows more about my specific problems.
OK, I am all here. While this post is indeed larger then previous, it is
not much more informative. Sorry. :(
I see several possibly unrelated problems there:
- crashes are always crashes. They should be debugged.
- calcru going backwards could have the same roots as lost wall clock
time. If there are some problems with timer interrupts, timecounters
could wrap unnoticed that will cause random time jumps.
- interactivity problems. I can't prove it is unrelated, but have no
real ideas now.
I would start from most obvious problems. I need to know more about
crashes. As usual: how to trigger, stack backtraces, etc.
What's about time problems, I would try to collect more data:
- show `sysctl kern.eventtimer`, `sysctl kern.timecounter` and verbose
dmesg outputs;
- what eventtimer is used now and does it helps to switch to another
one with kern.eventtimer.timer sysctl?
- does the timer runs in periodic or one-shot mode and does it helps to
switch to another one?
- if full CPU load makes time to stop, try to track what is going on
with timer interrupts using `vmstat -i` and `systat -vm 1`. Under full
CPU load in one-shot mode you should have stable timer interrupt rate
about hz+stathz.
- if timer interrupts are not working well, you can build kernel with
options KTR
options ALQ
options KTR_ALQ
options KTR_COMPILE=(KTR_SPARE2)
options KTR_ENTRIES=131072
options KTR_MASK=(KTR_SPARE2)
to track event timers operation and use ktrdump to save the trace when
problem exist (preferably when it begins).
And let's experiment with fresh CURRENT.
--
Alexander Motin