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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
