Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.

[Ingo Molnar <mingo@elte.hu>]

* john stultz <johnstul@us.ibm.com> wrote:

> > no, this is really a bad optimization that causes unrobustness. 
> > Correctness and robustness comes first. It is so easy to cause a 
> > 500-1000msec delay in the kernel, due to a bad driver or anything. The 
> > timekeeping code should not break like that.
> 
> Eh, its an easy enough change, so I'll put it back to u64. We can 
> revisit it again later if needed.

yeah. i didnt notice u64 hurting that much, and we can optimize it later 
on. As long as the 64-bit CPUs are ok, we shouldnt care all that much 
about micro-performance - especially not at the expense of robustness.

> However making sure periodic_hook isn't starved for too long is 
> important for good timekeeping, since ntp and cpufreq adjustments are 
> made at that point. Steven's suggestion of moving it to use ktimers 
> sounds like a good plan, but let me know if you can see any other 
> holes.

yes. Besides driver bugs and 'badly behaving' code, there's another use 
case: in the PREEMPT_RT kernel it's the user that picks the priorities 
for kernel functionalities in a very finegrained way: if his 
data-collection device interrupt and driver code is more important than 
anything else on the system (including timekeeping), then that's the way 
it will be. So the seemingly contradictory (and amusing) situation 
arises that the -rt kernel, which is all about low latencies, also 
increases the the need for subsystems to more robustly _bear with_ 
higher latencies - for the case where they happen to be the lowprio guy 
...

but i agree - excessive latencies cannot be tolerated - but up to a few 
seconds can easily happen in various situations.

	Ingo