On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html