Messages in this thread | | | Date | Sat, 27 Dec 2008 15:00:34 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] hrtimer: increase clock min delta threshold while interrupt hanging |
| |
On Sat, Dec 27, 2008 at 11:53:34AM +0100, Ingo Molnar wrote: > > * Frederic Weisbecker <fweisbec@gmail.com> wrote: > > > Impact: avoid hanging on 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 on several situation where something intrusive is slowing the > > system (ie: tracing) 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. > > > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > > Cc: Thomas Gleixner <tglx@linutronix.de> > > --- > > kernel/hrtimer.c | 30 +++++++++++++++++++++++++++++- > > 1 files changed, 29 insertions(+), 1 deletions(-) > > applied to tip/timers/hrtimers, thanks Frederic!
I will apply the comments that came along these reviews in a delta patch. Note that I still wonder about false positive with a 5 loop check. I think I will increase it to 10. This a more reasonable.
(I remember I had false positive but I'm not sure if that was because of early_printk used for debugging. I didn't worry about it first, because I hadn't these false positive on my last tests, just before I send this patch.)
> > Thomas, any objections/observations? > > Ingo
| |