From: Ingo Molnar <mingo@elte.hu>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] tracing/function-graph-tracer: prevent from hrtimer interrupt infinite loop
Date: Thu, 18 Dec 2008 22:44:58 +0100 [thread overview]
Message-ID: <20081218214458.GA30834@elte.hu> (raw)
In-Reply-To: <c62985530812181336m6ab39c8ah410dff763bd02d24@mail.gmail.com>
* Frédéric Weisbecker <fweisbec@gmail.com> wrote:
> > Which means that it's not some hrtimer problem, but simply the traced
> > timer tick takes more than 1 millisecond to execute under this
> > virtualization.
> >
> > Ingo
> >
>
> Oh ok I see. Sorry I'm a bit slow today... So the solution would be to
> adapt dynamically the timeout between hrtimer irq. But I don't know that
> much hrtimer to implement such a feature...
just if you want this lockup to go away. I think you did the hardest bit
already: to detect the situation reliably, without false positives. Now
the 'action' needs to change: instead of 'turning off ftrace' (which is
brutal - ftrace was just the last drop of water that pushed the system
over the edge), we can instead do 'double the minimum clockevent delta
threshold'.
there's already such code in kernel/time/tick-oneshot.c:
/*
* We tried 2 times to program the device with the given
* min_delta_ns. If that's not working then we double it
* and emit a warning.
*/
if (++i > 2) {
/* Increase the min. delta and try again */
if (!dev->min_delta_ns)
dev->min_delta_ns = 5000;
else
dev->min_delta_ns += dev->min_delta_ns >> 1;
what would be needed is to simply double ->min_delta_ns on every such
situation you detect? Once you do that, it takes effect on the next tick
automatically.
Or something like that. In theory. :-)
Ingo
next prev parent reply other threads:[~2008-12-18 21:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 1:09 [PATCH v2] tracing/function-graph-tracer: prevent from hrtimer interrupt infinite loop Frederic Weisbecker
2008-12-18 10:34 ` Ingo Molnar
2008-12-18 10:48 ` Thomas Gleixner
2008-12-18 10:56 ` Frédéric Weisbecker
2008-12-18 11:22 ` Ingo Molnar
2008-12-18 21:07 ` Frédéric Weisbecker
2008-12-18 21:16 ` Ingo Molnar
2008-12-18 21:36 ` Frédéric Weisbecker
2008-12-18 21:44 ` Ingo Molnar [this message]
2008-12-18 22:00 ` Frédéric Weisbecker
2008-12-21 10:00 ` Ingo Molnar
2008-12-21 10:12 ` Ingo Molnar
2008-12-21 12:21 ` Frédéric Weisbecker
2008-12-22 10:46 ` Frédéric Weisbecker
2008-12-18 10:51 ` Frédéric Weisbecker
2008-12-18 11:16 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081218214458.GA30834@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox