Re: [PATCH v2] perf tools: Allow passing perf's own pid to '--filter'

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Jul 07, 2015 at 10:19:12PM +0800, Wangnan (F) escreveu:
> 
> 
> On 2015/7/7 20:33, Namhyung Kim wrote:
> >Hi,
> >
> >On Tue, Jul 7, 2015 at 12:38 PM, Wang Nan <wangnan0@huawei.com> wrote:
> >>This patch allows passing perf's own PID to '--filter' by using
> >>'$PERFPID'. This should be useful when system-widely capturing
> >>tracepoints events.
> >>
> >>Before this patch, when doing something like:
> >>
> >>  # perf record -a -e syscalls:sys_enter_write <cmd>
> >>
> >>One could easily get result like this:
> >>
> >>  # perf report --stdio
> >>  ...
> >>  # Overhead  Command  Shared Object       Symbol
> >>  # ........  .......  ..................  ....................
> >>  #
> >>      99.99%  perf     libpthread-2.18.so  [.] __write_nocancel
> >>      0.01%   ls       libc-2.18.so        [.] write
> >>      0.01%   sshd     libc-2.18.so        [.] write
> >>      ...
> >>
> >>Where most events are generated by perf itself.
> >>
> >>A shell trick can be done to filter perf itself out:
> >>
> >>  # cat << EOF > ./tmp
> >>  > #!/bin/sh
> >>  > exec perf record -e ... --filter="common_pid != \$\$" -a sleep 10
> >>  > EOF
> >>  # chmod a+x ./tmp
> >>  # ./tmp
> >>
> >>However, doing so is user unfriendly.
> >>
> >>This patch introduces '$PERFPID' placeholder to perf's filter. Now
> >>user is allowed to do the above work with:
> >>
> >>   # perf record -e ... --filter='common_pid != $PERFPID' -a sleep 10
> >Instead, what about adding an option to do the same thing, like
> >--exclude-perf or something?
> 
> I thought this idea. Please see one of my previous email:
> 
> http://lkml.kernel.org/r/559B3CC3.2030503@huawei.com
> 
> This patch gives user full control of their filters. They can create filters
> like 'common_pid == $PERFPID' to profile perf itself, or use it in some
> complex expressions.
> 
> But if most of you like adding new option, I can post a v3 with
> '--exclude-perf' added. Yes, the code of it can be much simpler than this
> patch.

One other thing I thought is that the current way to apply --filter is
per tracepoint, i.e. parse_filter() goes on being called as we go on
parsing the command line and then it gets applied to the last --event
parsed, so if we want to apply the same filter to all tracepoints in a
more complex command line, then we must use that expression in each
tracepoint, no?

That provides more flexibility, as does being able to ask for some
specific tracepoint to be recorded only for the perf tool itself, and
for some specific tracepoint at that.

So it seems that for the problem you have at hand, i.e. exclude the perf
tool from all tracepoints in the command line, --exclude-perf seems more
compact, but since you already wrote the other patch to support
$PERF_PID, probably we should apply both?

- Arnaldo