Skip to content

Commit

Permalink
hrtimers: increase clock min delta threshold while interrupt hanging
Browse files Browse the repository at this point in the history
Impact: avoid timer IRQ hanging slow systems

While using the function graph tracer on a virtualized system, the
hrtimer_interrupt can hang the system on an infinite loop.

This can be caused in several situations:

 - the hardware is very slow and HZ is set too high

 - something intrusive is slowing the system down (tracing under emulation)

... and the next clock events to program are always before the current time.

This patch implements a reasonable compromise: if such a situation is
detected, we share the CPUs time in 1/4 to process the hrtimer interrupts.
This is enough to let the system running without serious starvation.

It has been successfully tested under VirtualBox with 1000 HZ and 100 HZ
with function graph tracer launched. On both cases, the clock events were
increased until about 25 ms periodic ticks, which means 40 HZ.

So we change a hard to debug hang into a warning message and a system that
still manages to limp along.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
  • Loading branch information
fweisbec authored and Ingo Molnar committed Jan 30, 2009
1 parent f2257b7 commit 7f22391
Showing 1 changed file with 29 additions and 1 deletion.
30 changes: 29 additions & 1 deletion kernel/hrtimer.c
Original file line number Diff line number Diff line change
Expand Up @@ -1158,6 +1158,29 @@ 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.
* 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
Expand All @@ -1167,13 +1190,18 @@ void hrtimer_interrupt(struct clock_event_device *dev)
struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
struct hrtimer_clock_base *base;
ktime_t expires_next, now;
int nr_retries = 0;
int i;

BUG_ON(!cpu_base->hres_active);
cpu_base->nr_events++;
dev->next_event.tv64 = KTIME_MAX;

retry:
/* 5 retries is enough to notice a hang */
if (!(++nr_retries % 5))
hrtimer_interrupt_hanging(dev, ktime_sub(ktime_get(), now));

now = ktime_get();

expires_next.tv64 = KTIME_MAX;
Expand Down Expand Up @@ -1226,7 +1254,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)

/* Reprogramming necessary ? */
if (expires_next.tv64 != KTIME_MAX) {
if (tick_program_event(expires_next, 0))
if (tick_program_event(expires_next, force_clock_reprogram))
goto retry;
}
}
Expand Down

0 comments on commit 7f22391

Please sign in to comment.