1. 23 3月, 2016 1 次提交
  2. 11 3月, 2016 2 次提交
    • N
      perf tools: Recalc total periods using top-level entries in hierarchy · f7fb538a
      Namhyung Kim 提交于
      When hierarchy mode is enabled, each entry in a hierarchy level shares
      the period.  IOW an upper level entry's period is the sum of lower level
      entries.  Thus perf uses only one of them to calculate the total period
      of hists.  It was lowest-level (leaf) entries but it has a problem when
      it comes to filters.
      
      If a filter is applied, entries in the same level will be filtered or
      not.  But upper level entries still have period of their sum including
      filtered one.  So total sum of upper level entries will not be same as
      sum of lower level entries.
      
      This resulted in entries having more than 100% of overhead and it can be
      produced using perf top with filter(s).
      Reported-and-Tested-by: NJiri Olsa <jolsa@kernel.org>
      Signed-off-by: NNamhyung Kim <namhyung@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/1457531222-18130-8-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f7fb538a
    • N
      perf tools: Fix command line filters in hierarchy mode · aec13a7e
      Namhyung Kim 提交于
      When a command-line filter is applied in hierarchy mode, output is
      broken especially when filtering on lower level.  The higher level
      entries doesn't show up so it's hard to see the results.
      
      Also it needs to handle multi sort keys in a single hierarchy level.
      
      Before:
      
        $ perf report --hierarchy -s 'cpu,{dso,comm}' --comms swapper --stdio
        ...
        #    Overhead  CPU / Shared Object+Command
        # ...........  ...........................
        #
               13.79%     [kernel.vmlinux]  swapper
            31.71%     000
               13.80%     [kernel.vmlinux]  swapper
                0.43%     [e1000e]          swapper
               11.89%     [kernel.vmlinux]  swapper
                9.18%     [kernel.vmlinux]  swapper
      
      After:
      
        #    Overhead  CPU / Shared Object+Command
        # ...........  ...............................
        #
            33.09%     003
               13.79%     [kernel.vmlinux]  swapper
            31.71%     000
               13.80%     [kernel.vmlinux]  swapper
                0.43%     [e1000e]          swapper
            21.90%     002
               11.89%     [kernel.vmlinux]  swapper
            13.30%     001
                9.18%     [kernel.vmlinux]  swapper
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-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/1457531222-18130-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      aec13a7e
  3. 08 3月, 2016 2 次提交
  4. 27 2月, 2016 3 次提交
    • N
      perf report: Update column width of dynamic entries · abab5e7f
      Namhyung Kim 提交于
      The column width of dynamic entries is updated when comparing hist
      entries.  However some unique entries can miss the chance to update.  So
      move the update to output resort stage to make sure every entry will get
      called before display.
      
      To do that, abuse ->sort callback to update the width when the third
      argument is NULL.  When resorting entries in normal path, it never be
      NULL so it should be fine IMHO.
      
      Before:
      
        #       Overhead  ptr / bytes_req / gfp_flags
        # ..............  ..........................................
        #
            37.50%        0xffff8803f7669400
               37.50%        448
                  37.50%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
            10.42%        0xffff8803f766be00
                8.33%        96
                   8.33%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
                2.08%        512
                   2.08%        GFP_KERNEL|GFP_NOWARN|GFP_REPEAT|GFP   <-- here
      
      After:
      
        #       Overhead  ptr / bytes_req / gfp_flags
        # ..............  .....................................................
        #
            37.50%        0xffff8803f7669400
               37.50%        448
                  37.50%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
            10.42%        0xffff8803f766be00
                8.33%        96
                   8.33%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
                2.08%        512
                   2.08%        GFP_KERNEL|GFP_NOWARN|GFP_REPEAT|GFP_NOMEMALLOC
      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-5-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      abab5e7f
    • N
      perf hists: Fix dynamic entry display in hierarchy · e049d4a3
      Namhyung Kim 提交于
      When dynamic sort key is used it might not show pretty printed output.
      This is because the trace output was not set only for the first dynamic
      sort key.  During hierarchy_insert_entry() it missed to pass the
      trace_output to dynamic entries.  Also even if it did, only first entry
      will have it.  Subsequent entries might set it during collapsing stage
      but it's not guaranteed.
      
      Before:
      
        $ perf report --hierarchy --stdio -s ptr,bytes_req,gfp_flags -g none
        #
        #       Overhead  ptr / bytes_req / gfp_flags
        # ..............  ..........................................
        #
            37.50%        0xffff8803f7669400
               37.50%        448
                  37.50%        66080
            10.42%        0xffff8803f766be00
                8.33%        96
                   8.33%        66080
                2.08%        512
                   2.08%        67280
      
      After:
      
        #
        #       Overhead  ptr / bytes_req / gfp_flags
        # ..............  ..........................................
        #
            37.50%        0xffff8803f7669400
               37.50%        448
                  37.50%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
            10.42%        0xffff8803f766be00
                8.33%        96
                   8.33%        GFP_ATOMIC|GFP_NOWARN|GFP_NOMEMALLOC
                2.08%        512
                   2.08%        GFP_KERNEL|GFP_NOWARN|GFP_REPEAT|GFP
      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-4-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e049d4a3
    • N
      perf hists: Fix comparing of dynamic entries · 84b6ee8e
      Namhyung Kim 提交于
      When hist_entry__cmp() and hist_entry__collapse() are called, they
      should check if the dynamic entry is comparing matching hists only.
      
      Otherwise it might access different hists resulting in incorrect output.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      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-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      84b6ee8e
  5. 26 2月, 2016 2 次提交
  6. 25 2月, 2016 6 次提交
  7. 22 2月, 2016 1 次提交
  8. 20 2月, 2016 2 次提交
  9. 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
  10. 03 2月, 2016 6 次提交
  11. 02 2月, 2016 2 次提交
  12. 26 1月, 2016 3 次提交
  13. 08 1月, 2016 2 次提交
  14. 07 1月, 2016 4 次提交
  15. 11 12月, 2015 1 次提交
  16. 10 12月, 2015 1 次提交
  17. 28 11月, 2015 1 次提交
    • N
      perf hists: Do not skip elided fields when processing samples · e72655d9
      Namhyung Kim 提交于
      If user gives a filter, perf marks the corresponding column elided and
      omits the output.  But it should process and aggregates samples using
      the field, otherwise samples will be aggregated as if the column was not
      there resulted in incorrect output.
      
      For example, I'd like to set a filter on native_write_msr_safe.  The
      original overhead of the function is negligible.
      
        $ perf report | grep native_write_msr_safe
            0.00%  swapper  [kernel.vmlinux]  native_write_msr_safe
            0.00%  perf     [kernel.vmlinux]  native_write_msr_safe
      
      However adding -S option gives different output.
      
        $ perf report -S native_write_msr_safe --percentage absolute | \
        > grep -e swapper -e perf
           51.47%  swapper  [kernel.vmlinux]
            4.14%  perf     [kernel.vmlinux]
      
      Since it aggregated samples using comm and dso only.  In fact, the above
      values are same when it sorts with -s comm,dso.
      
        $ perf report -s comm,dso | grep -e swapper -e perf
           51.47%  swapper  [kernel.vmlinux]
            4.14%  perf     [kernel.vmlinux]
      
      This resulted in TUI failure with -ERANGE since it tries to increase
      sample hit count for annotation with wrong symbols due to incorrect
      aggregation.
      
      This patch fixes it not to skip elided fields when comparing samples in
      order to insert them to the hists.
      
      Commiter note:
      
      After the patch, with a different workloads:
      
        # perf report --show-total-period -S native_write_msr_safe --stdio
        #
        # symbol: native_write_msr_safe
        #
        # Samples: 455  of event 'cycles:pp'
        # Event count (approx.): 134787489
        #
        # Overhead Period Command         Shared Object
        # ........ ...... ............... ................
        #
             0.22% 293081 qemu-system-x86 [vmlinux]
             0.19% 255914 swapper         [vmlinux]
             0.00%   2054 Timer           [vmlinux]
             0.00%   1021 firefox         [vmlinux]
             0.00%      2 perf            [vmlinux]
      
        # perf report --show-total-period | grep native_write_msr_safe
        Failed to open /tmp/perf-14838.map, continuing without symbols
             0.22% 293081 qemu-system-x86 [vmlinux]  [k] native_write_msr_safe
             0.19% 255914 swapper         [vmlinux]  [k] native_write_msr_safe
             0.00%   2054 Timer           [vmlinux]  [k] native_write_msr_safe
             0.00%   1021 firefox         [vmlinux]  [k] native_write_msr_safe
             0.00%      2 perf            [vmlinux]  [k] native_write_msr_safe
        #
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1448645559-31167-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e72655d9