Re: [PATCH 00/14] [GIT PULL][v2.6.39] tracing/filter: More robust filtering

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2011-02-15 at 05:44 +0100, Ingo Molnar wrote:
> hi Steve,
> 
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > Steven Rostedt (14):
> >       tracing/filter: Have no filter return a match
> >       tracing/filter: Move OR and AND logic out of fn() method
> >       tracing/filter: Dynamically allocate preds
> >       tracing/filter: Call synchronize_sched() just once for system filters
> >       tracing/filter: Allocate the preds in an array
> >       tracing/filter: Free pred array on disabling of filter
> >       tracing/filter: Use a tree instead of stack for filter_match_preds()
> >       tracing/filter: Optimize short ciruit check
> >       tracing/filter: Check the created pred tree
> >       tracing/filter: Optimize filter by folding the tree
> >       tracing/filter: Move MAX_FILTER_PRED to local tracing directory
> >       tracing/filter: Increase the max preds to 2^14
> >       tracing/filter: Swap entire filter of events
> >       tracing/filter: Remove synchronize_sched() from __alloc_preds()
> 
> I finally got around testing the various tracing filter features we have.
> 

[ snip all the perf output ]

> So ... i have to say that this tracing filter business is unusable crap from a user 
> POV right now and i see no reason to pull *anything* in this area until it does not 
> get improved to *much* better levels of usability and utility.
> 
> Nobody could *ever* have tested this with a 'naive but curious user' hat on and this 
> is really sad. We need to do much better!

Sorry I did not work with perf in writing this code. I was using the
debugfs directly. I figured that any improvement I made there would also
improve perf as I tried to make sure the perf hooks into that code were
updated too.

My question is, did this patch set cause any of the perf problems or did
these problems always exist?

I'm just saying that perf is not the only user. And to deny improvements
in the code because one user does not currently work well with them is
just hindering progress.

There happens to be real users out in the world that are still using
ftrace. I see no reason to stop improving it because your goal is to
have everyone move to perf.

Thanks for letting me waste three days on developing this. I even posted
an RFC a while back, and no one complained then.

-- Steve