Messages in this thread | | | Date | Thu, 18 Dec 2008 22:07:27 +0100 | From | "Frédéric Weisbecker" <> | Subject | Re: [PATCH v2] tracing/function-graph-tracer: prevent from hrtimer interrupt infinite loop |
| |
2008/12/18 Ingo Molnar <mingo@elte.hu>: > i meant that abstractly. The "solution" here is that your patch turns off > the function-graph-tracer. The practical effect of that is: the system > gets much faster at processing hrtimer IRQs and effectively "speeds up". > > ok? > > Ingo >
Ok :-)
> that would be important to double-check. Frederic, does the system lock up > with a periodic 1khz HZ tick just as much? I.e. does the processing of a > single timer interrupt take more than 1 milliseconds? > > Granted, if the system is too slow to process the system clock, it's not > useful. > > But that's my point: instead of just randomly disabling functionality > until the system gets 'fast enough' to process timer IRQs, how about > dynamically and adaptively extending the required minimal timeout between > hr-timer IRQs? > > That will in essence self-tune the system into some minimally working > state - instead of locking it up. Note that such a method would work with > any source of timer IRQ slowness - not just tracing. > > ( And maybe the lockup is somehow hrtimer IRQ induced. If a 1khz clock > still works for Frederic then that angle has to be investigated. ) > > Ingo >
Hmm. No, I just tested by setting 1000 HZ and disabled NOHZ, the system doesn't lockup unless I turn on the function graph tracer. That's strange. Perhaps I should look at the time elapsed between two retries on hrtimer_interrupts because it takes almost more than one second to disable tracing after I enabled it (that really too much for 10 interations inside hrtimer_interrupt, even with the time of tracing process).
| |