Re: [PATCH] tracing/filters: allow event filters to be set onlywhen not tracing

[Paul E. McKenney]

On Fri, Apr 03, 2009 at 03:59:56PM +0200, Ingo Molnar wrote:
> 
> * Tom Zanussi <tzanussi@xxxxxxxxx> wrote:
> 
> > On Wed, 2009-04-01 at 14:24 +0200, Ingo Molnar wrote:
> > > * Tom Zanussi <tzanussi@xxxxxxxxx> wrote:
> > > 
> > > > This patch adds code allowing the event filter to be set only if 
> > > > there's no active tracing going on.
> > > 
> > > > --- a/kernel/trace/trace_events.c
> > > > +++ b/kernel/trace/trace_events.c
> > > > @@ -498,6 +498,9 @@ event_filter_write(struct file *filp, const char __user *ubuf, size_t cnt,
> > > >  	struct filter_pred *pred;
> > > >  	int err;
> > > >  
> > > > +	if (tracing_is_enabled() && (!tracer_is_nop() || call->enabled))
> > > > +		return -EBUSY;
> > > 
> > > hm, but it would be the normal use-case to set filters on the fly. 
> > > To experiment around with them and shape them until the output is 
> > > just right. Having to turn the tracer on/off during that seems quite 
> > > counterproductive to that use-case.
> > > 
> > 
> > I didn't see anything that could be used to temporarily disable 
> > tracing (tracing_stop() and tracing_start() are 'quick' versions 
> > that mostly just disable recording), so did it this way to avoid 
> > adding any overhead to the filter-checking code.
> > 
> > But anyway, I'll post a new patch shortly that uses rcu and does 
> > allow the filters to be set on the fly.
> 
> that's a very intelligent way to do it!
> 
> There's a theoretical problem though: what if we put a filtered 
> tracepoint into the RCU code? Especially if that tracepoint is in 
> the common function-tracer callback affecting all kernel functions. 
> I've Cc:-ed Paul. I think the quiescent state logic should handle 
> this just fine, but i'm not 100% sure.

Disclaimer: I don't claim to fully understand the code.  I do not see any
problems tracing the quiescent-state logic.  However, it appears to me
that you don't get to set tracepoints in the idle loop for rcuclassic,
rcutree, and rcutiny.

My kneejerk reaction is "why would anyone want to trace the idle loop?"

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/