Messages in this thread | | | Date | Wed, 25 Nov 2015 12:02:57 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 1/2] ftrace: Add separate handler for ftrace:function event |
| |
On Wed, 25 Nov 2015 17:50:57 +0100 Jiri Olsa <jolsa@redhat.com> wrote:
> > This seems redundant. I never understood the control_ops that perf uses > > in the function tracing infrastructure. Why can't you just register the > > event->ops and have that ops set the filtering? Then the ftrace > > infrastructure will only call that event handler for the functions its > > filtered on. Then you don't need to do it again. Right now ftrace > > already does that with the generic "control_ops" that perf uses, but > > now you are doing it again. Seems rather pointless. > > well thats exactly what we are doing.. but as all ops > share single callback we need to find the proper event > this callback was triggered for
The ftrace_ops has a "private" field for the user to set. Could you make that point back to the event that allocated the ftrace_ops? Then the callback function could easily get the event that matches the ftrace_ops.
> > currently we use tracepoint callback (perf_tp_event) > where the proper event is found based on the event->filter > > however this is not the case for ftrace:function because > filter will not change the event->filter, but the ops filter
Yeah, I'm trying to figure out the paths here. I would love to remove the control_ops as that complicates the function tracing code a bit more than I would like it to be.
I just crashed function tracing by function tracing perf doing function tracing :-) I'm currently debugging that (and adding more code to help debug things like this).
-- Steve
| |