lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 7 Jul 2015 11:38:31 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	"Wangnan (F)" <wangnan0@...wei.com>
Cc:	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"Liang, Kan" <kan.liang@...el.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Andi Kleen <ak@...ux.intel.com>, jacob.w.shin@...il.com,
	standby24x7@...il.com, Li Zefan <lizefan@...wei.com>,
	yunlong.song@...wei.com, Steven Rostedt <rostedt@...dmis.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	pi3orama@....com
Subject: Re: [PATCH v2] perf tools: Allow passing perf's own pid to '--filter'

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@...wei.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ