Re: [RFC 5/5] perf: Enable multiple hist_entry_group output

[Don Zickus]

On Fri, Apr 11, 2014 at 07:30:00PM +0200, Jiri Olsa wrote:
> On Thu, Apr 10, 2014 at 04:11:01PM -0400, Don Zickus wrote:
> > Enable multiple hist_entry_group groups in the output based on a sort
> > method.
> > 
> > Currently only 'perf report' is hooked in with '--group-sort='.  The choices
> > are cpu, pid, and cacheline.  Only --stdio works right now.  I haven't figured
> > out how the other outputs work.
> > 
> > Sample output from 'perf mem record -a grep -r foo /* > /dev/null'
> > 
> > (normal) perf mem report --percent-limit=1.0 --stdio
> > 
> >  Overhead       Samples
> >   Local Weight             Memory access                                      Symbol
> >  ........  ............  ............  ........................  ........................
> > 
> >      4.13%             1  1759          Uncached hit              [k] ahci_scr_read
> >      1.16%             1  492           L1 hit                    [k] _raw_read_lock
> > 
> > (cpu groups) perf mem report --group-sort=cpu --percent-limit=1.0 --stdio
> > 
> >  Overhead       Samples  CPU
> >   Local Weight             Memory access                                      Symbol
> >  ........  ............  ............  ........................  ........................
> > 
> >     28.80%          1239   25
> > 	     3.07%               377           L1 hit                    [k] complete_walk
> > 	     2.76%               339           LFB hit                   [k] update_cfs_shares
> > 	     2.66%               326           LFB hit                   [k] copy_user_enhanced_f
> > 	     2.11%               259           Local RAM hit             [k] copy_user_enhanced_f
> > 	     1.84%               226           LFB hit                   [k] copy_user_enhanced_f
> > 	     1.74%               213           LFB hit                   [k] copy_user_enhanced_f
> > 	     1.53%               187           LFB hit                   [k] copy_user_enhanced_f
> > 	     1.04%               128           LFB hit                   [k] copy_user_enhanced_f
> > 	     1.01%               124           LFB hit                   [k] copy_user_enhanced_f
> >     27.44%           990    7
> > 	    15.06%               1759          Uncached hit              [k] ahci_scr_read
> > 	     4.21%               492           L1 hit                    [k] _raw_read_lock
> > 	     1.04%               122           LFB hit                   [k] find_busiest_group
> > 	     1.02%            1  7             L1 hit                    [.] __gconv_transform_ut
> >     20.34%          1010    0
> > 	     4.04%            5  7             L1 hit                    [k] poll_idle
> > 	     3.56%               308           Local RAM hit             [k] copy_user_enhanced_f
> > 	     2.59%               224           L3 hit                    [k] copy_user_enhanced_f
> > 	     2.12%               184           Local RAM hit             [k] copy_user_enhanced_f
> > 	     1.54%            1  7             L1 hit                    [.] __gconv_transform_ut
> 
> nice, that looks very usefull

\o/  :-)

> 
> Correct me if I'm wrong, but your current design allows to define
> just one group, right?

No, you can do multiple groups, ie --group-sort=cpu,pid,cacheline
(exactly the same way --sort works, in fact it uses the same sorting
functions and routines [pid_cmp is the _same_ in sort and group-sort]).
However, that is different than what you are asking below.  In my current
design, the output mimics --sorts output, just add sorted columns for each
group added.

> 
> so, current code can do following CPU sorting:
> 
>    Overhead   CPU
>    ........   ...
>    90%        0
>    10%        1
> 
> 
> and with your changes we could do:
> 
>    Overhead   CPU  symbol
>    ........   ...  ......
>    90%        0
>         50%        krava1
>         20%        krava2
>         30%        krava3
> 
>    10%        1
>         50%        krava4
>         50%        krava5
>   
> 
> I wonder we could go more generic and allow more nested groups,
> like eg allow group sort on cpu and pid (or more):

I never thought about that because I went in a different direction (as
described above), but I like the nested idea.  Coding it up would be much
trickier I think.  I would need to wrap my brain around it.

> 
>    Overhead   CPU  pid  symbol
>    ........   ...  ...  ......
>    90%        0
>       50%          100
>         50%             krava1
>         20%             krava2
>         30%             krava3
>       50%          110
>         50%             krava1
>         20%             krava2
>         30%             krava3
> 
>    10%        1
>       100%         200
>         50%             krava4
>         50%             krava5
> 
> 
> I glanced over the changes and I wonder we could do it
> by chaining hists structs via 'struct hist_entry'
> 
> like adding 'struct hists' into 'struct hists_entry'
> and making the sort_order local for each 'struct hists'

Well 'struct hists' was in 'struct hists_entry' (until this patchset
removed it).  :-)

We might be able to chain 'struct hists' somehow, though I am not sure how
to tell when a traverse a 'struct hists' vs. using 'entries' because we
hit an endpoint.  And if we have to write new sorting routines.  Also I
was originally keeping 'struct hists' as the upper level gatekeeper of
high level data, like filter_str and locks, col_len, etc.

I am not opposed to chaining, just thinking 'struct hists' isn't the right
struct to do it with.  I could be wrong. :-)  Will have to think about it.
Gives me something to thinking about next week on a plane to SF. :-)

Thanks for looking.

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/