1. 02 Jan, 2019 1 commit
  2. 31 Oct, 2018 1 commit
  3. 20 Sep, 2018 2 commits
  4. 19 Apr, 2017 1 commit
  5. 23 Jun, 2016 1 commit
    • Adrian Hunter's avatar
      perf script: Add callindent option · e216708d
      Adrian Hunter authored
      Based on patches from Andi Kleen.
      
      When printing PT instruction traces with perf script it is rather useful
      to see some indentation for the call tree. This patch adds a new
      callindent field to perf script that prints spaces for the function call
      stack depth.
      
      We already have code to track the function call stack for PT, that we
      can reuse with minor modifications.
      
      The resulting output is not quite as nice as ftrace yet, but a lot
      better than what was there before.
      
      Note there are some corner cases when the thread stack gets code
      confused and prints incorrect indentation. Even with that it is fairly
      useful.
      
      When displaying kernel code traces it is recommended to run as root, as
      otherwise perf doesn't understand the kernel addresses properly, and may
      not reset the call stack correctly on kernel boundaries.
      
      Example output:
      
      	sudo perf-with-kcore record eg2 -a -e intel_pt// -- sleep 1
      	sudo perf-with-kcore script eg2 --ns -F callindent,time,comm,pid,sym,ip,addr,flags,cpu --itrace=cre | less
      	...
               swapper     0 [000]  5830.389116586:   call        irq_exit                                                     ffffffff8104d620 smp_call_function_single_interrupt+0x30 => ffffffff8107e720 irq_exit
               swapper     0 [000]  5830.389116586:   call            idle_cpu                                                 ffffffff8107e769 irq_exit+0x49 => ffffffff810a3970 idle_cpu
               swapper     0 [000]  5830.389116586:   return          idle_cpu                                                 ffffffff810a39b7 idle_cpu+0x47 => ffffffff8107e76e irq_exit
               swapper     0 [000]  5830.389116586:   call            tick_nohz_irq_exit                                       ffffffff8107e7bd irq_exit+0x9d => ffffffff810f2fc0 tick_nohz_irq_exit
               swapper     0 [000]  5830.389116919:   call                __tick_nohz_idle_enter                               ffffffff810f2fe0 tick_nohz_irq_exit+0x20 => ffffffff810f28d0 __tick_nohz_idle_enter
               swapper     0 [000]  5830.389116919:   call                    ktime_get                                        ffffffff810f28f1 __tick_nohz_idle_enter+0x21 => ffffffff810e9ec0 ktime_get
               swapper     0 [000]  5830.389116919:   call                        read_tsc                                     ffffffff810e9ef6 ktime_get+0x36 => ffffffff81035070 read_tsc
               swapper     0 [000]  5830.389116919:   return                      read_tsc                                     ffffffff81035084 read_tsc+0x14 => ffffffff810e9efc ktime_get
               swapper     0 [000]  5830.389116919:   return                  ktime_get                                        ffffffff810e9f46 ktime_get+0x86 => ffffffff810f28f6 __tick_nohz_idle_enter
               swapper     0 [000]  5830.389116919:   call                    sched_clock_idle_sleep_event                     ffffffff810f290b __tick_nohz_idle_enter+0x3b => ffffffff810a7380 sched_clock_idle_sleep_event
               swapper     0 [000]  5830.389116919:   call                        sched_clock_cpu                              ffffffff810a738b sched_clock_idle_sleep_event+0xb => ffffffff810a72e0 sched_clock_cpu
               swapper     0 [000]  5830.389116919:   call                            sched_clock                              ffffffff810a734d sched_clock_cpu+0x6d => ffffffff81035750 sched_clock
               swapper     0 [000]  5830.389116919:   call                                native_sched_clock                   ffffffff81035754 sched_clock+0x4 => ffffffff81035640 native_sched_clock
               swapper     0 [000]  5830.389116919:   return                              native_sched_clock                   ffffffff8103568c native_sched_clock+0x4c => ffffffff81035759 sched_clock
               swapper     0 [000]  5830.389116919:   return                          sched_clock                              ffffffff8103575c sched_clock+0xc => ffffffff810a7352 sched_clock_cpu
               swapper     0 [000]  5830.389116919:   return                      sched_clock_cpu                              ffffffff810a7356 sched_clock_cpu+0x76 => ffffffff810a7390 sched_clock_idle_sleep_event
               swapper     0 [000]  5830.389116919:   return                  sched_clock_idle_sleep_event                     ffffffff810a7391 sched_clock_idle_sleep_event+0x11 => ffffffff810f2910 __tick_nohz_idle_enter
      	...
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarAndi Kleen <ak@linux.intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/1466689258-28493-4-git-send-email-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e216708d
  6. 06 May, 2016 2 commits
    • Chris Phlipot's avatar
      perf script: Expose usage of the callchain db export via the python api · 2c15f5eb
      Chris Phlipot authored
      This change allows python scripts to be able to utilize the recent
      changes to the db export api allowing the export of call_paths derived
      from sampled callchains. These call paths are also now associated with
      the samples from which they were derived.
      
      - This feature is enabled by setting "perf_db_export_callchains" to true
      
      - When enabled, samples that have callchain information will have the
        callchains exported via call_path_table
      
      - The call_path_id field is added to sample_table to enable association of
        samples with the corresponding callchain stored in the call paths
        table. A call_path_id of 0 will be exported if there is no
        corresponding callchain.
      
      - When "perf_db_export_callchains" and "perf_db_export_calls" are both
        set to True, the call path root data structure will be shared. This
        prevents duplicating of data and call path ids that would result from
        building two separate call path trees in memory.
      
      - The call_return_processor structure definition was relocated to the header
        file to make its contents visible to db-export.c. This enables the
        sharing of call path trees between the two features, as mentioned
        above.
      
      This change is visible to python scripts using the python db export api.
      
      The change is backwards compatible with scripts written against the
      previous API, assuming that the scripts model the sample_table function
      after the one in export-to-postgresql.py script by allowing for
      additional arguments to be added in the future. ie. using *x as the
      final argument of the sample_table function.
      Signed-off-by: default avatarChris Phlipot <cphlipot0@gmail.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1461831551-12213-6-git-send-email-cphlipot0@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2c15f5eb
    • Chris Phlipot's avatar
      perf tools: Refactor code to move call path handling out of thread-stack · 451db126
      Chris Phlipot authored
      Move the call path handling code out of thread-stack.c and
      thread-stack.h to allow other components that are not part of
      thread-stack to create call paths.
      
      Summary:
      
      - Create call-path.c and call-path.h and add them to the build.
      
      - Move all call path related code out of thread-stack.c and thread-stack.h
        and into call-path.c and call-path.h.
      
      - A small subset of structures and functions are now visible through
        call-path.h, which is required for thread-stack.c to continue to
        compile.
      
      This change is a prerequisite for subsequent patches in this change set
      and by itself contains no user-visible changes.
      Signed-off-by: default avatarChris Phlipot <cphlipot0@gmail.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1461831551-12213-3-git-send-email-cphlipot0@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      451db126
  7. 19 Jun, 2015 1 commit
  8. 03 Nov, 2014 2 commits