Hello Thomas, On Tue, Sep 15, 2009 at 05:29:17PM +0200, Thomas Gleixner wrote: > 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. OK. > > 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. hrtimer_interrupt_hanging() can decrease min_delta_ns. Look at Bo's reports: min_delta_ns is initially 61036 and he gets hrtimer: interrupt too slow, forcing clock min delta to 52482 ns If you want I can add a WARN_ON_ONCE((unsigned long)try_time.tv64 * 3 < dev->min_delta_ns) and send you the output of dmesg. > > 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. Hhhhm, doesn't destroy that any upper bound for latency. If a process succeeds to install many timers that expire one after another with a short delta in between min_delta_ns goes up. This in turn mean that even high priority processes loose the ability to sleep a short period. > > 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 ? http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=commitdiff;h=a1b46573904d822ac5c7495ea1dbc8ef38200bf7 > > - 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. The critic be right, I haven't thought much about that, didn't even try it. My thought was only that in the original case (delta <= 0) the event to program is in the past, so programming min_delta_ns for it isn't too early at all. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
