lkml.org 
[lkml]   [2008]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] hrtimer: increase clock min delta threshold while interrupt hanging

* Frans Pop <elendil@planet.nl> 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.
>
> Should there maybe also be a mechanism to allow the system to
> automatically "recover" to higher (the original?) clockfrequencies, for
> example if the danger of loops has passed after tracing has been
> disabled?

I dont think that's necessary - tick_dev_program_event() already includes
a gradual approach that increases the 'min delta' interval step by step -
so we should find the 'system is limping along' compromise pretty
accurately.

A system can get "magically faster" later on (if we turn off tracing or
other kernel features that impact the cost of the timer tick), and we
might not need those safety measures anymore - but here the real solution
will be to make the virtualizer faster. Taking milliseconds to process a
timer tick (be that under tracing or not) is rather slow. So the kernel
has applied the brakes and has printed a warning about it - we should do
no more.

> > +static int force_clock_reprogram;
>
> Shouldn't this be initialized to 0?

no - global or static scope variables are initialized to zero in C.

> > @@ -1239,7 +1267,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;
> >         }
> >  }
>
> Shouldn't force_clock_reprogram be reset to 0 after it has fired and
> been handled?

hm, that would be interesting to see - in theory the system should become
stable after a few iterations of increasing min_delta. Frederic, is the
system still workable if you try what Frans has suggested?

Also, there's min_delta doubling in tick_dev_program_event() itself too -
that interacts with the irq-overload logic:

+ dev->min_delta_ns = (unsigned long)try_time.tv64 * 3;

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2008-12-22 08:03    [W:0.102 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site