From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Tom Zanussi <tzanussi@gmail.com>, Ingo Molnar <mingo@elte.hu>,
linux-kernel <linux-kernel@vger.kernel.org>,
fweisbec@gmail.com
Subject: Re: [PATCH] tracing/filters: allow event filters to be set only when not tracing
Date: Sat, 4 Apr 2009 10:02:14 -0700 [thread overview]
Message-ID: <20090404170214.GE6893@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0904041143480.32083@gandalf.stny.rr.com>
On Sat, Apr 04, 2009 at 11:49:30AM -0400, Steven Rostedt wrote:
> On Sat, 4 Apr 2009, Tom Zanussi wrote:
> >
> > Hmm, after reading Paul's replies, it sounds like this approach might be
> > more trouble than it's worth. Maybe going back to the idea of
> > temporarily stopping/starting tracing would be a better idea, but with a
> > little more heavyweight version of the current 'quick' tracing
> > start/stop (that would prevent entering the tracing functions (and ththe
> > filter_check_discard()).
>
> Actually, I forgot what the general problem we are avoiding here with the
> RCU locks. Could you explain that again. Just so that I can get a better
> idea without having to read between the lines of the previous messages in
> this thread.
I would be interested in hearing this as well.
Thanx, Paul
> > I was thinking it would be something like:
> >
> > stop_tracing();
> > current_tracer->stop(); /* unregister tracepoints, etc */
> >
> > remove filter
> >
> > current_tracer->start(); /* reregister tracepoints, etc */
> > start_tracing();
>
> This use to be the way start and stop worked, but I'm trying to
> make them more light weight. I've been wanting start/stop to be called
> by start_tracing() and stop_tracing() and those should be able to be
> called in any context. But registering and unregistering tracepoints calls
> mutexes, which can not be done in atomic context.
>
> There are still some tracers that have start/stop using sleeping code, but
> in the long run I want the tracers start/stop functions to be light.
>
>
> >
> > The struct tracer comments suggest that the stop()/start()
> > ops are meant for pausing, I'd guess for things like this, but some of
> > the tracers don't implement them.
>
> Yeah, They should, but leaving out the start/stop functions, is just
> the tracers way of saying, I don't need to pause. :-/
>
> >
> > For the events in the event tracer, it would be something like:
> >
> > stop_tracing();
> > call->unregfunc(); /* unregister tracepoint */
> >
> > remove filter
> >
> > call->regfunc(); /* reregister tracepoint */
> > start_tracing();
> >
> > If that makes sense, I can try it that way instead.
> >
>
> I'll comment about this if I get that explanation of the problem again ;-)
>
> -- Steve
>
next prev parent reply other threads:[~2009-04-04 17:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 5:22 [PATCH] tracing/filters: allow event filters to be set only when not tracing Tom Zanussi
2009-04-01 12:24 ` Ingo Molnar
2009-04-02 6:22 ` Tom Zanussi
2009-04-03 13:59 ` Ingo Molnar
2009-04-03 14:12 ` Steven Rostedt
2009-04-04 7:32 ` Tom Zanussi
2009-04-04 15:49 ` Steven Rostedt
2009-04-04 17:02 ` Paul E. McKenney [this message]
2009-04-05 7:34 ` Tom Zanussi
2009-04-05 17:11 ` Paul E. McKenney
2009-04-06 15:59 ` Steven Rostedt
2009-04-06 16:15 ` Paul E. McKenney
2009-04-06 19:30 ` Steven Rostedt
2009-04-06 19:44 ` Frederic Weisbecker
2009-04-06 19:52 ` Steven Rostedt
2009-04-06 20:15 ` Paul E. McKenney
2009-04-06 23:58 ` Paul E. McKenney
2009-04-07 0:34 ` Steven Rostedt
2009-04-07 1:27 ` Paul E. McKenney
2009-04-03 16:26 ` Paul E. McKenney
2009-04-03 16:37 ` Ingo Molnar
2009-04-03 16:43 ` Steven Rostedt
2009-04-03 18:05 ` Paul E. McKenney
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=20090404170214.GE6893@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
/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