From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sasha Levin <sasha.levin@oracle.com>,
Dave Jones <davej@redhat.com>, Tejun Heo <tj@kernel.org>,
tglx@linutronix.de, LKML <linux-kernel@vger.kernel.org>,
trinity@vger.kernel.org
Subject: Re: timer: lockup in run_timer_softirq()
Date: Thu, 11 Jul 2013 19:11:57 +0200 [thread overview]
Message-ID: <20130711171157.GL25631@dyad.programming.kicks-ass.net> (raw)
In-Reply-To: <1373561972.17876.51.camel@gandalf.local.home>
On Thu, Jul 11, 2013 at 12:59:32PM -0400, Steven Rostedt wrote:
> On Thu, 2013-07-11 at 12:55 -0400, Steven Rostedt wrote:
>
> > >
> > > Other than that, a function tracer environment that is safer to use might be
> > > useful for other people as well.
> >
> > Not sure how to make the environment safe, as the main purpose of the
> > function trace is to debug those hard to debug locations, like NMIs,
> > RCU, dynamic ticks, etc. To ensure a "safe" environment, it would
> > cripple the tracer.
> >
> > Hmm, what would you state as a safe environment? How can we detect if
> > the environment is safe to trace or not?
>
> Maybe I misunderstood you. You mean to have this environment be
> something for not just perf, and have the macro be:
>
> NONSAFE_TRACE(__local_bh_enable);
>
> ?
>
> Then, any ftrace user could set a flag in the registering of its ops to
> 'safe_only_functions'. And it will ignore all of these locations.
> There's really not many of them, so it may not be too hard to weed out.
Yah, like that. But that doesn't invalidate your question as to what 'safe'
would encompass. I think RCU/lockdep would be the big thing for perf, not
sure it should be wider than that.
next prev parent reply other threads:[~2013-07-11 17:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 22:35 timer: lockup in run_timer_softirq() Sasha Levin
2013-07-09 22:47 ` Dave Jones
2013-07-09 22:49 ` Sasha Levin
2013-07-09 23:03 ` Dave Jones
2013-07-09 23:09 ` Sasha Levin
2013-07-10 9:52 ` Peter Zijlstra
2013-07-10 12:27 ` Steven Rostedt
2013-07-10 12:42 ` Peter Zijlstra
2013-07-10 12:58 ` Steven Rostedt
2013-07-11 16:42 ` Peter Zijlstra
2013-07-11 16:55 ` Steven Rostedt
2013-07-11 16:59 ` Steven Rostedt
2013-07-11 17:11 ` Peter Zijlstra [this message]
2014-04-03 20:43 ` Sasha Levin
2013-07-10 9:54 ` Peter Zijlstra
2013-07-10 14:47 ` Sasha Levin
2013-07-11 10:02 ` Peter Zijlstra
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=20130711171157.GL25631@dyad.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sasha.levin@oracle.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=trinity@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.