1. 27 2月, 2016 2 次提交
    • N
      perf report: Left align dynamic entries in hierarchy · cb1fab91
      Namhyung Kim 提交于
      The dynamic entries are right-aligned unlike other entries since it
      usually has numeric value.  But for the hierarchy mode, left alignment
      is more appropriate IMHO.  Also trim spaces on the left so that we can
      easily identify the hierarchy.
      
      Before:
      
        $ perf report --hierarchy -i perf.data.kmem -s gfp_flags,ptr,bytes_req --stdio -g none
        ...
        #
        #       Overhead                                        gfp_flags /                ptr /          bytes_req
        # ..............  .................................................................................................
        #
            91.67%                   GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
               37.50%        0xffff8803f7669400
                  37.50%                       448
                8.33%        0xffff8803f766be00
                   8.33%                        96
                4.17%        0xffff8800d156dc00
                   4.17%                       704
      
      After:
      
        #       Overhead  gfp_flags / ptr / bytes_req
        # ..............  ....................................
        #
            91.67%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
               37.50%        0xffff8803f7669400
                  37.50%        448
                8.33%        0xffff8803f766be00
                   8.33%        96
                4.17%        0xffff8800d156dc00
                   4.17%        704
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1456512767-1164-3-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cb1fab91
    • N
      perf report: Fix indentation of dynamic entries in hierarchy · d3a72fd8
      Namhyung Kim 提交于
      When dynamic entries are used in the hierarchy mode with multiple
      events, the output might not be aligned properly.  In the hierarchy
      mode, the each sort column is indented using total number of sort keys.
      So it keeps track of number of sort keys when adding them.  However
      a dynamic sort key can be added more than once when multiple events have
      same field names.  This results in unnecessarily long indentation in the
      output.
      
      For example perf kmem records following events:
      
        $ perf evlist --trace-fields -i perf.data.kmem
        kmem:kmalloc: trace_fields: call_site,ptr,bytes_req,bytes_alloc,gfp_flags
        kmem:kmalloc_node: trace_fields: call_site,ptr,bytes_req,bytes_alloc,gfp_flags,node
        kmem:kfree: trace_fields: call_site,ptr
        kmem:kmem_cache_alloc: trace_fields: call_site,ptr,bytes_req,bytes_alloc,gfp_flags
        kmem:kmem_cache_alloc_node: trace_fields: call_site,ptr,bytes_req,bytes_alloc,gfp_flags,node
        kmem:kmem_cache_free: trace_fields: call_site,ptr
        kmem:mm_page_alloc: trace_fields: page,order,gfp_flags,migratetype
        kmem:mm_page_free: trace_fields: page,order
      
      As you can see, many field names shared between kmem events.  So adding
      'ptr' dynamic sort key alone will set nr_sort_keys to 6.  And this adds
      many unnecessary spaces between columns.
      
      Before:
      
        $ perf report -i perf.data.kmem --hierarchy -s ptr -g none --stdio
        ...
        #                Overhead                 ptr
        # .......................  ...................................
        #
            99.89%                 0xffff8803ffb79720
             0.06%                 0xffff8803d228a000
             0.03%                 0xffff8803f7678f00
             0.00%                 0xffff880401dc5280
             0.00%                 0xffff880406172380
             0.00%                 0xffff8803ffac3a00
             0.00%                 0xffff8803ffac1600
      
      After:
      
        # Overhead                 ptr
        # ........  ....................
        #
            99.89%  0xffff8803ffb79720
             0.06%  0xffff8803d228a000
             0.03%  0xffff8803f7678f00
             0.00%  0xffff880401dc5280
             0.00%  0xffff880406172380
             0.00%  0xffff8803ffac3a00
             0.00%  0xffff8803ffac1600
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1456512767-1164-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d3a72fd8
  2. 26 2月, 2016 1 次提交
    • N
      perf report: Show message for percent limit on stdio · bd4abd39
      Namhyung Kim 提交于
      When the hierarchy mode is used, some entries might be omiited due to a
      percent limit or filter.  In this case the output hierarchy is different
      than other entries.  Add an informative message to users about this.
      
      For example, when 4% of percent limit is applied:
      
      Before:
        #       Overhead  Command / Shared Object / Symbol
        # ..............  ..........................................
        #
            49.09%        swapper
               48.67%        [kernel.vmlinux]
                  34.42%        [k] intel_idle
            11.51%        firefox
                8.87%        libpthread-2.22.so
                   6.60%        [.] __GI___libc_recvmsg
            10.49%        gnome-shell
                4.74%        libc-2.22.so
            10.08%        Xorg
                6.11%        libc-2.22.so
                   5.27%        [.] __memcpy_sse2_unaligned
             6.15%        perf
      
      Note that, gnome-shell/libc has no symbols and perf has no dso/symbols.
      With that patch the output will look like below:
      
      After:
      
        #       Overhead  Command / Shared Object / Symbol
        # ..............  ..........................................
        #
            49.09%        swapper
               48.67%        [kernel.vmlinux]
                  34.42%        [k] intel_idle
            11.51%        firefox
                8.87%        libpthread-2.22.so
                   6.60%        [.] __GI___libc_recvmsg
            10.49%        gnome-shell
                4.74%        libc-2.22.so
                                no entry >= 4.00%
            10.08%        Xorg
                6.11%        libc-2.22.so
                   5.27%        [.] __memcpy_sse2_unaligned
             6.15%        perf
                             no entry >= 4.00%
      Suggested-and-Tested-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1456488800-28124-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bd4abd39
  3. 25 2月, 2016 2 次提交
  4. 12 2月, 2016 1 次提交
    • A
      perf hists: Do column alignment on the format iterator · 89fee709
      Arnaldo Carvalho de Melo 提交于
      We were doing column alignment in the format function for each cell,
      returning a string padded with spaces so that when the next column is
      printed the cursor is at its column alignment.
      
      This ends up needlessly printing trailing spaces, do it at the format
      iterator, that is where we know if it is needed, i.e. if there is more
      columns to be printed.
      
      This eliminates the need for triming lines when doing a dump using 'P'
      in the TUI browser and also produces far saner results with things like
      piping 'perf report' to 'less'.
      
      Right now only the formatters for sym->name and the 'locked' column
      (perf mem report), that are the ones that end up at the end of lines
      in the default 'perf report', 'perf top' and 'perf mem report' tools,
      the others will be done in a subsequent patch.
      
      In the end the 'width' parameter for the formatters now mean, in
      'printf' terms, the 'precision', where before it was the field 'width'.
      Reported-by: NDave Jones <davej@codemonkey.org.uk>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/n/tip-s7iwl2gj23w92l6tibnrcqzr@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      89fee709
  5. 03 2月, 2016 2 次提交
  6. 02 2月, 2016 4 次提交
  7. 07 1月, 2016 1 次提交
    • N
      perf tools: Skip dynamic fields not defined for current event · 361459f1
      Namhyung Kim 提交于
      When there are multiple events, each dynamic sort key is defined just
      for one event.  In this case other events will always show "N/A" for
      those fields.  But they are meaningless and consume precious screen
      width.
      
      Let's skip those undefined dynamic fields.
      
        $ perf record -e kmem:kmalloc,kmem:kfree -a sleep 1
      
        $ perf report -s 'comm,kmalloc.*' --stdio
        # To display the perf.data header info, please use --header/--header-only options.
        #
        #
        # Total Lost Samples: 0
        #
        # Samples: 20K of event 'kmem:kmalloc'
        # Event count (approx.): 20533
        #
        # Overhead  Command           call_site                 ptr  bytes_req  bytes_alloc            gfp_flags
        # ........  .......  ..................  ..................  .........  ...........  ...................
        #
            99.89%  perf       ffffffffa01d4396  0xffff8803ffb79720         96           96    GFP_NOFS|GFP_ZERO
             0.06%  sleep      ffffffff8114e1cd  0xffff8803d228a000       4096         4096           GFP_KERNEL
             0.03%  perf       ffffffff811d6ae6  0xffff8803f7678f00        240          256  GFP_KERNEL|GFP_ZERO
             0.00%  perf       ffffffff812263c1  0xffff880406172380        128          128           GFP_KERNEL
             0.00%  perf       ffffffff812264b9  0xffff8803ffac1600        504          512           GFP_KERNEL
             0.00%  perf       ffffffff81226634  0xffff880401dc5280         28           32           GFP_KERNEL
             0.00%  sleep      ffffffff81226da9  0xffff8803ffac3a00        392          512           GFP_KERNEL
      
        # Samples: 20K of event 'kmem:kfree'
        # Event count (approx.): 20597
        #
        # Overhead  Command
        # ........  ..............
        #
            99.63%  perf
             0.14%  sleep
             0.11%  irq/36-iwlwifi
             0.11%  kworker/u16:0
             0.01%  Xorg
             0.00%  firefox
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1450804030-29193-12-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      361459f1
  8. 20 11月, 2015 3 次提交
  9. 19 11月, 2014 1 次提交
  10. 12 8月, 2014 1 次提交
  11. 17 7月, 2014 1 次提交
  12. 01 6月, 2014 2 次提交
  13. 21 5月, 2014 4 次提交
  14. 28 4月, 2014 1 次提交
    • A
      perf tools: Allocate thread map_groups's dynamically · 93d5731d
      Arnaldo Carvalho de Melo 提交于
      Moving towards sharing map groups within a process threads.
      
      Because of this we need the map groups to be dynamically allocated. No
      other functional change is intended in here.
      
      Based on a patch by Jiri Olsa, but this time _just_ making the
      conversion from statically allocating thread->mg to turning it into a
      pointer and instead of initializing it at thread's constructor,
      introduce a constructor/destructor for the map_groups class and
      call at thread creation time.
      
      Later we will introduce the get/put methods when we move to sharing
      those map_groups, when the get/put refcounting semantics will be needed.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1397490723-1992-3-git-send-email-jolsa@redhat.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      93d5731d
  15. 15 3月, 2014 2 次提交
  16. 28 12月, 2013 1 次提交
  17. 06 11月, 2013 1 次提交
  18. 29 10月, 2013 1 次提交
  19. 06 9月, 2013 1 次提交
  20. 13 7月, 2013 2 次提交
  21. 28 5月, 2013 1 次提交
  22. 01 2月, 2013 1 次提交
  23. 25 1月, 2013 1 次提交
  24. 09 12月, 2012 1 次提交
  25. 06 10月, 2012 1 次提交
  26. 05 10月, 2012 1 次提交