public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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