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: [PATCH perf/core v3 3/3] [BUGFIX] perf probe: Show usage even if the last event is skipped
Date: Wed, 17 Jun 2015 14:31:07 +0900 [thread overview]
Message-ID: <5581061B.8030701@hitachi.com> (raw)
In-Reply-To: <20150616144655.GE10374@kernel.org>
On 2015/06/16 23:46, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 16, 2015 at 08:50:57PM +0900, Masami Hiramatsu escreveu:
>> When the last part of converted events are blacklisted or out-of-text,
>> those are skipped and perf probe doesn't show usage examples.
>> This fixes it to show the example even if the last part of event list
>> is skipped.
>>
>> E.g. without this patch, events are added, but suddenly end;
>
> End what? Stop being added?
"End without the last message", I meant.
> I.e. not all eligible events are added? From
> your description the problem seems to be that that last message: "You
> can now use it..." is not presented, but here, without this patch, it
> is:
I see, actually, this happens only if the skipped symbols (
vfs_caches_init_early or vfs_caches_init) are placed at the end of the
matched symbol list. On Ubuntu 15.04 kernel, it doesn't have
vfs_load_quota_inode etc. and the vfs_caches_init is the last part of
the matched list. Since it is hard to reproduce, I've added a Note on
the end of description :)
----
>>
>> Note that this can be reproduced ONLY IF the vfs_caches_init*
>> is the last part of matched symbol list. I've checked this happens
>> on "3.19.0-generic #18-Ubuntu" kernel binary.
>>
----
To reproduce this bug, you need to find a good symbol matching pattern
which (1) matches both of valid function in .text and invalid function
in .inittext (2) invalid one must be on the end of matched function list.
I fortunately hit such pattern and found this bug, but it depends on
the kernel binary.
[...]
> 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...
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 5:31 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 [this message]
2015-06-17 14:58 ` Masami Hiramatsu
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=5581061B.8030701@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.