linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).