Messages in this thread | | | Date | Fri, 9 Mar 2018 09:38:14 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] perf report: Show zero counters as well in 'perf report --stat' |
| |
* Arnaldo Carvalho de Melo <acme@kernel.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
| |