Re: [PATCH] perf tool sort: Use default sort if evlist is empty

From: David Carrillo-Cisneros
Date: Mon Jul 24 2017 - 06:43:30 EST


On Sat, Jul 22, 2017 at 4:09 PM, Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> On Fri, Jul 21, 2017 at 01:02:50PM -0700, David Carrillo-Cisneros wrote:
>> On Fri, Jul 21, 2017 at 12:44 AM, Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>> > 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:
>>
>> I see this hard to do since, at any given point while traversing the
>> pipe's content, the best we can do is guess that we've seen all event
>> types. Then we'd need to fall back and redo the output whenever a new
>> sample refutes our last guess.
>
> After reading feature event, you could know the number of events, no?

True. Also the tool could extract the events from HEADER_EVENT_DESC
feature event and adjust output accordingly. That'd be a nice to have
feature.

Thanks,
David