From: Jiri Olsa <jolsa@redhat.com>
To: David Carrillo-Cisneros <davidcc@google.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>, Simon Que <sque@chromium.org>,
Wang Nan <wangnan0@huawei.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Stephane Eranian <eranian@google.com>,
Paul Turner <pjt@google.com>
Subject: Re: [PATCH] perf tool sort: Use default sort if evlist is empty
Date: Fri, 21 Jul 2017 09:44:44 +0200 [thread overview]
Message-ID: <20170721074444.GB29613@krava> (raw)
In-Reply-To: <20170721051157.47331-1-davidcc@google.com>
On Thu, Jul 20, 2017 at 10:11:57PM -0700, David Carrillo-Cisneros wrote:
> Fixes bug noted by Jiri in https://lkml.org/lkml/2017/6/13/755 and caused
> by commit d49dadea7862 ("perf tools: Make 'trace' or 'trace_fields' sort
> key default for tracepoint events")
> not taking into account that evlist is empty in pipe-mode.
>
> Before this commit, pipe mode will only show bogus "100.00% N/A" instead
> of correct output as follows:
>
> $ perf record -o - sleep 1 | perf report -i -
> # To display the perf.data header info, please use --header/--header-only options.
> #
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.000 MB - ]
> #
> # Total Lost Samples: 0
> #
> # Samples: 8 of event 'cycles:ppH'
> # Event count (approx.): 145658
> #
> # Overhead Trace output
> # ........ ............
> #
> 100.00% N/A
>
> Correct output, after patch:
>
> $ perf record -o - sleep 1 | perf report -i -
> # To display the perf.data header info, please use --header/--header-only options.
> #
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.000 MB - ]
> #
> # Total Lost Samples: 0
> #
> # Samples: 8 of event 'cycles:ppH'
> # Event count (approx.): 191331
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... ................. .................................
> #
> 81.63% sleep libc-2.19.so [.] _exit
> 13.58% sleep ld-2.19.so [.] do_lookup_x
> 2.34% sleep [kernel.kallsyms] [k] context_switch
> 2.34% sleep libc-2.19.so [.] __GI___libc_nanosleep
> 0.11% perf [kernel.kallsyms] [k] __intel_pmu_enable_a
>
I wonder we could reinit the sortorder once we know what
events we have in pipe, and recognize the tracepoint output
properly:
[root@krava perf]# ./perf record -e 'sched:sched_switch' sleep 1 | ./perf report
# To display the perf.data header info, please use --header/--header-only options.
SNIP
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ..............
#
100.00% sleep [kernel.kallsyms] [k] __schedule
also I've got another crash for (added -a option for above example):
[root@krava perf]# ./perf record -e 'sched:sched_switch' -a sleep 1 | ./perf report
# To display the perf.data header info, please use --header/--header-only options.
#
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.000 MB (null) ]
Segmentation fault (core dumped)
catchsegv got:
/home/jolsa/kernel/linux-perf/tools/perf/util/ordered-events.c:85(free_dup_event)[0x51a6a5]
./perf(ordered_events__free+0x5c)[0x51b0b7]
/home/jolsa/kernel/linux-perf/tools/perf/util/session.c:1751(__perf_session__process_pipe_events)[0x518abb]
./perf(perf_session__process_events+0x91)[0x5190f0]
/home/jolsa/kernel/linux-perf/tools/perf/builtin-report.c:598(__cmd_report)[0x443a91]
./perf(cmd_report+0x169b)[0x4455a3]
/home/jolsa/kernel/linux-perf/tools/perf/perf.c:296(run_builtin)[0x4be1b0]
/home/jolsa/kernel/linux-perf/tools/perf/perf.c:348(handle_internal_command)[0x4be41d]
/home/jolsa/kernel/linux-perf/tools/perf/perf.c:395(run_argv)[0x4be56f]
./perf(main+0x2d6)[0x4be949]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f3de8a10401]
./perf(_start+0x2a)[0x42831a]
looks like some mem corruption.. will try to follow up
on this later if nobody beats me to it ;-)
thanks,
jirka
next prev parent reply other threads:[~2017-07-21 7:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 5:11 [PATCH] perf tool sort: Use default sort if evlist is empty David Carrillo-Cisneros
2017-07-21 7:44 ` Jiri Olsa [this message]
2017-07-21 20:02 ` David Carrillo-Cisneros
2017-07-22 23:09 ` Namhyung Kim
2017-07-24 7:47 ` Jiri Olsa
2017-07-24 10:43 ` David Carrillo-Cisneros
2017-07-26 20:03 ` 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=20170721074444.GB29613@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=davidcc@google.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pjt@google.com \
--cc=sque@chromium.org \
--cc=wangnan0@huawei.com \
/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.