On Tue, 15 Sep 2009, Uwe Kleine-König wrote: > Hello, > > I'm able to reproduce this now. The problem is really that > hrtimer_interrupt() tries to program the next timer event which fails 4 > times in a row, because the expiry time is already in the past when > tick_dev_program_event is called. This happens because there are so > much timers with small expiry times. (cyclictest -t40 on an UP machine) Pretty much the case which triggers the hang mechanism. > Addionally the fourth interation was short (probably because then there > were no expired timers to check for) and so the try_time argument to > hrtimer_interrupt_hanging was small and so min_delta_ns was decreased > instead of increased. He, what is decreasing min_delta_ns ? There is no such code. > I wonder why increasing min_delta_ns is supposed to fix something here. > Actually some pressure that results in hrtimer_interrupt_hanging being > called can always happen independently of min_delta_ns' value. It ensures that the timer interrupts are delayed sufficiently that something else than the timer interrupt has a chance to get on the CPU. > And moreover, is it sensible to change the value of > force_clock_reprogram? This makes the system harder to benchmark, > because to guarantee a certain latency now you have to check both > situations force_clock_reprogram==1 and force_clock_reprogram==0. > > My suggestion is to do the following: > - fix hrtimer_interrupt_hanging not to decrease min_delta_ns It does not decrease anything, so what's to fix there ? > - in clockevents_program_event instead of > if (delta <= 0) > return -ETIME; > do > if (delta <= -dev->min_delta_ns) > return -ETIME; > > I'm not sure though if -dev->min_delta_ns is the right value or if > that is a good idea at all. You might expire timers early, which is wrong. Thanks, tglx
