On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote: > On Wed, 7 Oct 2009, Marcelo Tosatti wrote: > > On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote: > > What about getting rid of the retry loop, instead? So something > > like: > > > > - run hrtimer callbacks (once) > > - while (tick_program_event(expires)) > > expires = ktime_add_ns(expires, dev->min_delta_ns) > > > > This way there's no static tuning involved. > > And what does that buy us ? We get an timer interrupt right away, so > it's not that much different from the retry loop. See below. > > > Its not clear to me why the loop is there in the first place. > > We get a timer interrupt and handle the expired timers and find out > the timer which is going to expire next to reprogram the hardware. Now > when we program that expiry time we find out that the timer is already > expired. So instead of programming the hardware to fire an interrupt > in the very near future which you would do with your loop above we > stay in the interrupt handler and expire the timer and any other by > now expired timers right away. > > The hang check is just there to avoid starving (slow) machines. We do > this by spreading the timer interrupts out so that the system can do > something else than expiring timers. OK, makes sense. So why not program only the next tick using the heuristic, without touching min_delta_ns? diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index c03f221..4fcb670 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1178,29 +1178,16 @@ static void __run_hrtimer(struct hrtimer *timer) #ifdef CONFIG_HIGH_RES_TIMERS -static int force_clock_reprogram; - /* * After 5 iteration's attempts, we consider that hrtimer_interrupt() * is hanging, which could happen with something that slows the interrupt - * such as the tracing. Then we force the clock reprogramming for each future - * hrtimer interrupts to avoid infinite loops and use the min_delta_ns - * threshold that we will overwrite. + * such as the tracing. * The next tick event will be scheduled to 3 times we currently spend on * hrtimer_interrupt(). This gives a good compromise, the cpus will spend * 1/4 of their time to process the hrtimer interrupts. This is enough to * let it running without serious starvation. */ -static inline void -hrtimer_interrupt_hanging(struct clock_event_device *dev, - ktime_t try_time) -{ - force_clock_reprogram = 1; - dev->min_delta_ns = (unsigned long)try_time.tv64 * 3; - printk(KERN_WARNING "hrtimer: interrupt too slow, " - "forcing clock min delta to %lu ns\n", dev->min_delta_ns); -} /* * High resolution timer interrupt * Called with interrupts disabled @@ -1219,8 +1206,16 @@ void hrtimer_interrupt(struct clock_event_device *dev) retry: /* 5 retries is enough to notice a hang */ - if (!(++nr_retries % 5)) - hrtimer_interrupt_hanging(dev, ktime_sub(ktime_get(), now)); + if (!(++nr_retries % 5)) { + ktime_t try_time = ktime_sub(ktime_get(), now); + + do { + for (i = 0; i < 3; i++) + expires_next = ktime_add(expires_next,try_time); + } while (tick_program_event(expires_next, 0)); + + return; + } now = ktime_get(); @@ -1286,7 +1281,7 @@ void hrtimer_interrupt(struct clock_event_device *dev) /* Reprogramming necessary ? */ if (expires_next.tv64 != KTIME_MAX) { - if (tick_program_event(expires_next, force_clock_reprogram)) + if (tick_program_event(expires_next, 0)) goto retry; } } -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html