[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180311195416.GB13895@krava>
Date: Sun, 11 Mar 2018 20:54:16 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...IV.linux.org.uk>,
Tom Zanussi <tom.zanussi@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 0/3] tracing: Rewrite the function filter code
On Fri, Mar 09, 2018 at 09:34:42PM -0500, Steven Rostedt wrote:
SNIP
> Special thanks goes out to Al for his patience and his time that he spent in
> educating us in a proper logical parser.
>
> Two patches were added to do some initial clean up. The last patch
> implements Al's suggestions. I wrote up a very lengthy comment describing
> what Al taught us in my own words (hopefully I got it right), and the
> implementation is similar to what Al showed with a few changes (again,
> hopefully I got that right too). I tested this with lots of different
> filters and it looks to be holding up.
>
>
> Jiri,
>
> This affects perf as well. I ran some tests and I believe I got
> it woking as it does today.
nice, it looks ok to me.. I guess the only concern is the filter for
ftrace:function event, which uses the pred parsing code just to get
the 'ip == ...' pairs and feeds it to ftrace_ops filter api
I'll check and make some tests
I think tracepoint events filters should be working without any special
care because they use the same api as ftrace filters
jirka
Powered by blists - more mailing lists