From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Naohiro Aota <naota@elisp.net>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Ahern <dsahern@gmail.com>,
namhyung@kernel.org, Jiri Olsa <jolsa@redhat.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: Re: [PATCH perf/core v3 3/3] [BUGFIX] perf probe: Show usage even if the last event is skipped
Date: Wed, 17 Jun 2015 23:58:18 +0900 [thread overview]
Message-ID: <55818B0A.4030506@hitachi.com> (raw)
In-Reply-To: <5581061B.8030701@hitachi.com>
On 2015/06/17 14:31, Masami Hiramatsu wrote:
>> > I.e. the only problem I found was this:
>> >
>> > [root@zoo ~]# time perf probe -l > /dev/null
>> >
>> > real 0m15.408s
>> > user 0m14.892s
>> > sys 0m0.534s
>> > [root@zoo ~]#
>> > [root@zoo ~]# perf stat perf probe -l > /dev/null
>> >
>> > Performance counter stats for 'perf probe -l':
>> >
>> > 15256.588897 task-clock (msec) # 1.001 CPUs utilized
>> > 116 context-switches # 0.008 K/sec
>> > 4 cpu-migrations # 0.000 K/sec
>> > 230,720 page-faults # 0.015 M/sec
>> > 47,830,405,530 cycles # 3.135 GHz
>> > 43,974,134,505 stalled-cycles-frontend # 91.94% frontend cycles idle
>> > <not supported> stalled-cycles-backend
>> > 11,540,587,038 instructions # 0.24 insns per cycle
>> > # 3.81 stalled cycles per insn
>> > 2,807,769,592 branches # 184.037 M/sec
>> > 20,087,075 branch-misses # 0.72% of all branches
>> >
>> > 15.240796324 seconds time elapsed
>> >
>> > [root@zoo ~]#
>> >
>> > Can you check why it takes so long and check the need for this patch?
> It is because perf probe -l is not optimized to show a lot of probes yet.
> It initializes and loads debuginfo for each probe. I guess we can reuse
> debuginfo among them. let me try...
>
OK, I've ensured that's true,
[root@localhost perf]# time ./perf probe -l &> /dev/null
real 0m25.376s
user 0m24.381s
sys 0m1.012s
[root@localhost perf]# time ./perf probe --no-dwarf -l &> /dev/null
real 0m0.059s
user 0m0.039s
sys 0m0.020s
(Note that --no-dwarf is my local patch for debugging, not sending yet)
So, the problem is on the debuginfo processing. I've also fixed that
by caching the last used debuginfo. :)
[root@localhost perf]# time ./perf probe -l &> /dev/null
real 0m0.161s
user 0m0.136s
sys 0m0.025s
I'll send the patch asap.
Thank you!
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2015-06-17 14:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 11:50 [PATCH perf/core v3 0/3] perf-probe bugfixes Masami Hiramatsu
2015-06-16 11:50 ` [PATCH perf/core v3 1/3] [BUGFIX] perf probe: List probes in stdout Masami Hiramatsu
2015-06-16 11:50 ` [PATCH perf/core v3 2/3] [BUGFIX] perf probe: Fix to return error if no-probe is added Masami Hiramatsu
2015-06-18 8:15 ` [tip:perf/core] perf probe: Fix to return error if no probe " tip-bot for Masami Hiramatsu
2015-06-16 11:50 ` [PATCH perf/core v3 3/3] [BUGFIX] perf probe: Show usage even if the last event is skipped Masami Hiramatsu
2015-06-16 14:46 ` Arnaldo Carvalho de Melo
2015-06-17 5:31 ` Masami Hiramatsu
2015-06-17 14:58 ` Masami Hiramatsu [this message]
2015-06-17 14:58 ` [PATCH perf/core ] perf probe: Speed up perf probe --list by caching debuginfo Masami Hiramatsu
2015-06-18 8:17 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-06-17 15:00 ` Re: [PATCH perf/core v3 3/3] [BUGFIX] perf probe: Show usage even if the last event is skipped Arnaldo Carvalho de Melo
2015-06-18 8:16 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-06-16 13:48 ` [PATCH perf/core v3 0/3] perf-probe bugfixes Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55818B0A.4030506@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=acme@kernel.org \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=naota@elisp.net \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.