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

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

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):

   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'

just first thoughts.. need to look at it closely ;-)

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to