Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1561723 > unrolled thread

Re: [PATCH 07/11] perf, tools: Collapse identically named events in perf stat

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 07/11] perf, tools: Collapse identically named events in  perf stat Jiri Olsa <jolsa@redhat.com> - 2017-01-18 13:50 +0100
    Re: [PATCH 07/11] perf, tools: Collapse identically named events in  perf stat Andi Kleen <ak@linux.intel.com> - 2017-01-18 17:40 +0100
      Re: [PATCH 07/11] perf, tools: Collapse identically named events in  perf stat Jiri Olsa <jolsa@redhat.com> - 2017-01-18 18:00 +0100
        Re: [PATCH 07/11] perf, tools: Collapse identically named events in  perf stat Andi Kleen <ak@linux.intel.com> - 2017-01-18 18:30 +0100

#1561723 — Re: [PATCH 07/11] perf, tools: Collapse identically named events in perf stat

On Tue, Jan 03, 2017 at 07:08:29AM -0800, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> The uncore PMU has a lot of duplicated PMUs for different subsystems.
> When expanding an uncore alias we usually end up with a large
> number of identically named aliases, which makes perf stat
> output difficult to read.
> 
> Automatically sum them up in perf stat, unless --no-merge is specified.
> 
> This can be default because only the uncores generally have duplicated
> aliases. Other PMUs have unique names.
> 
> Before:
> 
> % perf stat --no-merge -a  -e unc_c_llc_lookup.any sleep 1
> 
>  Performance counter stats for 'system wide':
> 
>            694,976 Bytes unc_c_llc_lookup.any
>            706,304 Bytes unc_c_llc_lookup.any
>            956,608 Bytes unc_c_llc_lookup.any
>            782,720 Bytes unc_c_llc_lookup.any
>            605,696 Bytes unc_c_llc_lookup.any
>            442,816 Bytes unc_c_llc_lookup.any
>            659,328 Bytes unc_c_llc_lookup.any
>            509,312 Bytes unc_c_llc_lookup.any
>            263,936 Bytes unc_c_llc_lookup.any
>            592,448 Bytes unc_c_llc_lookup.any
>            672,448 Bytes unc_c_llc_lookup.any
>            608,640 Bytes unc_c_llc_lookup.any
>            641,024 Bytes unc_c_llc_lookup.any
>            856,896 Bytes unc_c_llc_lookup.any
>            808,832 Bytes unc_c_llc_lookup.any
>            684,864 Bytes unc_c_llc_lookup.any
>            710,464 Bytes unc_c_llc_lookup.any
>            538,304 Bytes unc_c_llc_lookup.any
> 
>        1.002577660 seconds time elapsed
> 
> After:
> 
> % perf stat  -a  -e unc_c_llc_lookup.any sleep 1
> 
>  Performance counter stats for 'system wide':
> 
>          2,685,120 Bytes unc_c_llc_lookup.any
> 
>        1.002648032 seconds time elapsed


if one of them is not supported, we get wrong output:


[jolsa@krava perf]$ sudo ./perf stat --no-merge -a  -e clockticks sleep 1

 Performance counter stats for 'system wide':

   <not supported>      clockticks                                                  
         4,925,158      clockticks                                                  

       1.000982200 seconds time elapsed

[jolsa@krava perf]$ sudo ./perf stat  -a  -e clockticks sleep 1

 Performance counter stats for 'system wide':

   <not supported>      clockticks                                                  

       1.000850195 seconds time elapsed

jirka

[toc] | [next] | [standalone]

#1561948

> > % perf stat  -a  -e unc_c_llc_lookup.any sleep 1
> > 
> >  Performance counter stats for 'system wide':
> > 
> >          2,685,120 Bytes unc_c_llc_lookup.any
> > 
> >        1.002648032 seconds time elapsed
> 
> 
> if one of them is not supported, we get wrong output:


I would argue the output is not incorrect, after all it is not supported
if something is missing. 

Imagine this is run with an interval:

If we changed the number of output lines based on some dynamic scheduling
condition this could confuse post processing scripts or users. Some output
records would be completely different than others. So marking everything
merged <not supported> in these cases is better and more consistent.

It is also difficult to change and should be a rare condition.

-Andi

[toc] | [prev] | [next] | [standalone]

#1561954

On Wed, Jan 18, 2017 at 08:31:26AM -0800, Andi Kleen wrote:
> > > % perf stat  -a  -e unc_c_llc_lookup.any sleep 1
> > > 
> > >  Performance counter stats for 'system wide':
> > > 
> > >          2,685,120 Bytes unc_c_llc_lookup.any
> > > 
> > >        1.002648032 seconds time elapsed
> > 
> > 
> > if one of them is not supported, we get wrong output:
> 
> 
> I would argue the output is not incorrect, after all it is not supported
> if something is missing. 
> 
> Imagine this is run with an interval:
> 
> If we changed the number of output lines based on some dynamic scheduling
> condition this could confuse post processing scripts or users. Some output
> records would be completely different than others. So marking everything
> merged <not supported> in these cases is better and more consistent.
> 
> It is also difficult to change and should be a rare condition.

will it always show 'not supported', as I haven't found this in the
changelog I guess you did not know about this behaviour?

could you also please document it somewhere

jirka

[toc] | [prev] | [next] | [standalone]

#1561985

> will it always show 'not supported', as I haven't found this in the
> changelog I guess you did not know about this behaviour?

Not guaranteed. Will fix that.

> 
> could you also please document it somewhere

Ok.

-Andi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web