linux-kernel - Re: [PATCH] perf report: Show zero counters as well in 'perf report --stat'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 9 Mar 2018 09:38:14 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Arnaldo Carvalho de Melo <acme@...radead.org>,
        Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf report: Show zero counters as well in 'perf report
 --stat'


* Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> >             STAT events:          0
> >       STAT_ROUND events:          0
> >     EVENT_UPDATE events:          0
> >        TIME_CONV events:          1
> >          FEATURE events:          0
> > 
> > It's pretty clear at a glance that LOST_SAMPLES is present but zero.
> 
> Your wording confused me a bit, that "is present" part, because there
> are some PERF_RECORD_ events that will only be "present" if we actually
> explicitely ask them to be, by setting flags in perf_event_attr, like:
> 
> 				mmap           :  1, /* include mmap data     */
> 				comm	       :  1, /* include comm data     */
> 				task           :  1, /* trace fork/exit       */
> 				mmap_data      :  1, /* non-exec mmap data    */
> 				sample_id_all  :  1, /* sample_type all events */
> 				mmap2          :  1, /* include mmap with inode data     */
> 				comm_exec      :  1, /* flag comm events that are due to an exec */
> 				context_switch :  1, /* context switch data */
> 				namespaces     :  1, /* include namespaces data */
> 
> So, for PERF_RECORD_MMAP2 events, one can say that it is "present but
> zero" if we have an event with perf_event_attr.mmap2 = 1 and no
> PERF_RECORD_MMAP2 events recorded.
> 
> But for PERF_RECORD_LOST, that will always be present, if we lose
> records.

Yeah, the triple ambiguity between:

  -    did the event disappear due to 'we did not lose any records',
  - or did it disappear because it's somehow a conditional stat field,
  - or did it disappear because I'm blind and/or mis-remembering the field name.

... is what was causing trouble to me personally, to the level that I had to go 
and look into the tooling code to make sure I'm interpreting it correctly.

> So perhaps to make all this clean we can add your patch, and on top of
> it another that shows the perf_record_attr flag for the ones that are
> not on all the time, something like:
> 
>    fomalhaut:~> perf report --stat
>  
>    Aggregated stats:
>             TOTAL events:     495984
>              MMAP events:         85	attr.mmap: 1
>              LOST events:          0
>              COMM events:       3389	attr.comm: 1, attr.comm_exec: 0
>              EXIT events:       1605    attr.task: 1
>          THROTTLE events:          2
>        UNTHROTTLE events:          2
>              FORK events:       3377	attr.task: 1
>              READ events:          0
>            SAMPLE events:     472629
>             MMAP2 events:      14753	attr.mmap2: 1
>               AUX events:          0    have to look at what enables this, etc
>      ITRACE_START events:          0	ditto
>      LOST_SAMPLES events:          0
>            SWITCH events:          0	attr.context_switch: 0
>   SWITCH_CPU_WIDE events:          0	attr.context_switch: 0
>        NAMESPACES events:          0	attr.namespaces: 0
>              ATTR events:          0
>        EVENT_TYPE events:          0
>      TRACING_DATA events:          0
>          BUILD_ID events:          0	this implies disabling in 'perf record' command line
>    FINISHED_ROUND events:        139
>          ID_INDEX events:          0
>     AUXTRACE_INFO events:          0
>          AUXTRACE events:          0
>    AUXTRACE_ERROR events:          0
>        THREAD_MAP events:          1
>           CPU_MAP events:          1
>       STAT_CONFIG events:          0
>              STAT events:          0
>        STAT_ROUND events:          0
>      EVENT_UPDATE events:          0
>         TIME_CONV events:          1	have to check
>           FEATURE events:          0

Yeah, I'm fine with this too if it's easy enough to implement - although I suspect 
in most cases the knowledge that a stat field not present must be due to an 
environment/setup dependency (and not a runtime/workload dependency) is enough.

It's the uncertainty of 'stat line can disappear because it was zero' that was my 
main beef :-)

Thanks,

	Ingo