1. 12 8月, 2017 2 次提交
    • T
      perf record: Fix wrong size in perf_record_mmap for last kernel module · 9ad4652b
      Thomas Richter 提交于
      During work on perf report for s390 I ran into the following issue:
      
      0 0x318 [0x78]: PERF_RECORD_MMAP -1/0:
              [0x3ff804d6990(0xfffffc007fb2966f) @ 0]:
              x /lib/modules/4.12.0perf1+/kernel/drivers/s390/net/qeth_l2.ko
      
      This is a PERF_RECORD_MMAP entry of the perf.data file with an invalid
      module size for qeth_l2.ko (the s390 ethernet device driver).
      
      Even a mainframe does not have 0xfffffc007fb2966f bytes of main memory.
      
      It turned out that this wrong size is created by the perf record
      command.  What happens is this function call sequence from
      __cmd_record():
      
        perf_session__new():
          perf_session__create_kernel_maps():
            machine__create_kernel_maps():
              machine__create_modules():   Creates map for all loaded kernel modules.
                modules__parse():   Reads /proc/modules and extracts module name and
                                    load address (1st and last column)
                  machine__create_module():   Called for every module found in /proc/modules.
                                    Creates a new map for every module found and enters
                                    module name and start address into the map. Since the
                                    module end address is unknown it is set to zero.
      
      This ends up with a kernel module map list sorted by module start
      addresses.  All module end addresses are zero.
      
      Last machine__create_kernel_maps() calls function map_groups__fixup_end().
      This function iterates through the maps and assigns each map entry's
      end address the successor map entry start address. The last entry of the
      map group has no successor, so ~0 is used as end to consume the remaining
      memory.
      
      Later __cmd_record calls function record__synthesize() which in turn calls
      perf_event__synthesize_kernel_mmap() and perf_event__synthesize_modules()
      to create PERF_REPORT_MMAP entries into the perf.data file.
      
      On s390 this results in the last module qeth_l2.ko
      (which has highest start address, see module table:
              [root@s8360047 perf]# cat /proc/modules
              qeth_l2 86016 1 - Live 0x000003ff804d6000
              qeth 266240 1 qeth_l2, Live 0x000003ff80296000
              ccwgroup 24576 1 qeth, Live 0x000003ff80218000
              vmur 36864 0 - Live 0x000003ff80182000
              qdio 143360 2 qeth_l2,qeth, Live 0x000003ff80002000
              [root@s8360047 perf]# )
      to be the last entry and its map has an end address of ~0.
      
      When the PERF_RECORD_MMAP entry is created for kernel module qeth_l2.ko
      its start address and length is written. The length is calculated in line:
          event->mmap.len   = pos->end - pos->start;
      and results in 0xffffffffffffffff - 0x3ff804d6990(*) = 0xfffffc007fb2966f
      
      (*) On s390 the module start address is actually determined by a __weak function
      named arch__fix_module_text_start() in machine__create_module().
      
      I think this improvable. We can use the module size (2nd column of /proc/modules)
      to get each loaded kernel module size and calculate its end address.
      Only for map entries which do not have a valid end address (end is still zero)
      we can use the heuristic we have now, that is use successor start address or ~0.
      Signed-off-by: NThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Reviewed-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Cc: Zvonko Kosic <zvonko.kosic@de.ibm.com>
      LPU-Reference: 20170803134902.47207-2-tmricht@linux.vnet.ibm.com
      Link: http://lkml.kernel.org/n/tip-nmoqij5b5vxx7rq2ckwu8iaj@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9ad4652b
    • M
      perf util: Take elf_name as const string in dso__demangle_sym · 80c345b2
      Milian Wolff 提交于
      The input string is not modified and thus can be passed in as a pointer
      to const data.
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Link: http://lkml.kernel.org/r/20170806212446.24925-3-milian.wolff@kdab.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      80c345b2
  2. 03 5月, 2017 1 次提交
    • P
      perf symbols: Allow user probes on versioned symbols · d8040645
      Paul Clarke 提交于
      Symbol versioning, as in glibc, results in symbols being defined as:
      
        <real symbol>@[@]<version>
      
      (Note that "@@" identifies a default symbol, if the symbol name is
      repeated.)
      
      perf is currently unable to deal with this, and is unable to create user
      probes at such symbols:
      
        --
        $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
        0000000000008d30 t __pthread_create_2_1
        0000000000008d30 T pthread_create@@GLIBC_2.17
        $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create
        probe-definition(0): pthread_create
        symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
        Try to find probe point from debuginfo.
        Probe point 'pthread_create' not found.
           Error: Failed to add events. Reason: No such file or directory (Code: -2)
        --
      
      One is not able to specify the fully versioned symbol, either, due to
      syntactic conflicts with other uses of "@" by perf:
      
        --
        $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create@@GLIBC_2.17
        probe-definition(0): pthread_create@@GLIBC_2.17
        Semantic error :SRC@SRC is not allowed.
        0 arguments
           Error: Command Parse Error. Reason: Invalid argument (Code: -22)
        --
      
      This patch ignores versioning for default symbols, thus allowing probes to be
      created for these symbols:
      
        --
        $ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 pthread_create
        Added new event:
           probe_libpthread:pthread_create (on pthread_create in /lib/powerpc64le-linux-gnu/libpthread-2.19.so)
      
        You can now use it in all perf tools, such as:
      
                 perf record -e probe_libpthread:pthread_create -aR sleep 1
      
        $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
        $ /usr/bin/sudo ./perf script
                     test  2915 [000] 19124.260729: probe_libpthread:pthread_create: (3fff99248d38)
                     test  2916 [000] 19124.260962: probe_libpthread:pthread_create: (3fff99248d38)
        $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
        Removed event: probe_libpthread:pthread_create
        --
      
      Committer note:
      
      Change the variable storing the result of strlen() to 'int', to fix the build
      on debian:experimental-x-mipsel, fedora:24-x-ARC-uClibc, ubuntu:16.04-x-arm,
      etc:
      
        util/symbol.c: In function 'symbol__match_symbol_name':
        util/symbol.c:422:11: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
           if (len < versioning - name)
                   ^
      Signed-off-by: NPaul A. Clarke <pc@us.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Link: http://lkml.kernel.org/r/c2b18d9c-17f8-9285-4868-f58b6359ccac@us.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d8040645
  3. 20 4月, 2017 1 次提交
  4. 27 3月, 2017 2 次提交
  5. 21 3月, 2017 1 次提交
  6. 30 11月, 2016 1 次提交
    • D
      perf script: Add option to stop printing callchain · 64eff7d9
      David Ahern 提交于
      Allow user to specify list of symbols which cause the dump of callchains
      to stop at that symbol.
      
      Committer notes:
      
      Testing it:
      
        # perf record -ag usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 1.177 MB perf.data (33 samples) ]
        #
        # # Without it:
        #
        # perf script
        swapper   0 [000]  9693.370039:          1 cycles:ppp:
                        2072ad x86_pmu_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        326978 flush_smp_call_function_queue (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        327413 generic_smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        249b37 smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        a04b2c call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        889427 cpuidle_enter (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        2e534a call_cpuidle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        2e5730 cpu_startup_entry (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        9f5167 rest_init (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                       137ffeb start_kernel ([kernel.vmlinux].init.text)
                       137f2ca x86_64_start_reservations ([kernel.vmlinux].init.text)
                       137f419 x86_64_start_kernel ([kernel.vmlinux].init.text)
      
        swapper   0 [000]  9693.370044:          1 cycles:ppp:
                        20ca1b intel_pmu_handle_irq (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        205b0c perf_event_nmi_handler (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a14a nmi_handle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a6b3 default_do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a83c do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        a03fb1 end_repeat_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        326978 flush_smp_call_function_queue (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        327413 generic_smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        249b37 smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        a04b2c call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        889427 cpuidle_enter (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        2e534a call_cpuidle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        2e5730 cpu_startup_entry (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        9f5167 rest_init (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                       137ffeb start_kernel ([kernel.vmlinux].init.text)
                       137f2ca x86_64_start_reservations ([kernel.vmlinux].init.text)
        #
        # # Using it to see just what are the calls from the 'remote_function' function:
        #
        # perf script --stop-bt remote_function
        swapper   0 [000]  9693.370039:          1 cycles:ppp:
                        2072ad x86_pmu_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
      
        swapper   0 [000]  9693.370044:          1 cycles:ppp:
                        20ca1b intel_pmu_handle_irq (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        205b0c perf_event_nmi_handler (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a14a nmi_handle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a6b3 default_do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        22a83c do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        a03fb1 end_repeat_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                        3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1480104021-36275-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      64eff7d9
  7. 25 11月, 2016 1 次提交
    • N
      perf sched timehist: Mark schedule function in callchains · cdeb01bf
      Namhyung Kim 提交于
      The sched_switch event always captured from the scheduler function.  So
      it'd be great omit them from the callchain.  This patch marks the
      functions to be omitted by later patch.
      
      Committer notes:
      
      Testing it:
      
      Before:
      
        [root@jouet experimental]# perf sched record -g ls
        Dockerfile  perf.data  x-mips64
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 1.355 MB perf.data (29 samples) ]
        [root@jouet experimental]# perf sched timehist
            time  cpu  task name         wait time sch delay run time
                       [tid/pid]             (msec) (msec) (msec)
        ----------- -----  ----------------- ------ ------ ------
        6.494998 [001] <idle>                0.000  0.000  0.000
        6.495027 [002] perf[519]             0.000  0.000  0.000 __schedule <- schedule <- schedule_hrtimeout_range_clock <- schedule_hrtimeou
        6.495096 [003] <idle>                0.000  0.000  0.000
        6.495100 [003] rcuos/0[9]            0.000  0.005  0.003 __schedule <- schedule <- rcu_nocb_kthread <- kthread <- ret_from_fork
        6.495113 [001] perf[520]             0.000  0.008  0.114 __schedule <- preempt_schedule_common <- _cond_resched <- wait_for_completion
        6.495121 [000] <idle>                0.000  0.000  0.000
        6.495129 [001] migration/1[17]       0.000  0.003  0.016 __schedule <- schedule <- smpboot_thread_fn <- kthread <- ret_from_fork
        6.496085 [002] <idle>                0.000  0.000  1.057
        6.496096 [002] kworker/u16:1[31169]  0.000  0.004  0.011 __schedule <- schedule <- worker_thread <- kthread <- ret_from_fork
        6.496096 [003] <idle>                0.003  0.000  0.996
        6.496169 [002] <idle>                0.011  0.000  0.072
        6.496171 [000] ls[520]               0.008  0.000  1.049 __schedule <- schedule <- do_exit <- do_group_exit <- [unknown]
        6.496172 [003] gnome-terminal-[4391] 0.000  0.003  0.076 __schedule <- schedule <- schedule_hrtimeout_range_clock <- schedule_hrtimeo
      
      After:
      
        [root@jouet experimental]# perf sched timehist
            time  cpu  task name         wait time sch delay run time
                       [tid/pid]            (msec)  (msec)  (msec)
        ----------- -----  ----------------- -----  -----  ------
        6.494998 [001] <idle>                0.000  0.000  0.000
        6.495027 [002] perf[519]             0.000  0.000  0.000 schedule_hrtimeout_range_clock <- schedule_hrtimeout_range <- poll_schedule_t
        6.495096 [003] <idle>                0.000  0.000  0.000
        6.495100 [003] rcuos/0[9]            0.000  0.005  0.003 rcu_nocb_kthread <- kthread <- ret_from_fork
        6.495113 [001] perf[520]             0.000  0.008  0.114 preempt_schedule_common <- _cond_resched <- wait_for_completion <- stop_one_c
        6.495121 [000] <idle>                0.000  0.000  0.000
        6.495129 [001] migration/1[17]       0.000  0.003  0.016 smpboot_thread_fn <- kthread <- ret_from_fork
        6.496085 [002] <idle>                0.000  0.000  1.057
        6.496096 [002] kworker/u16:1[31169]  0.000  0.004  0.011 worker_thread <- kthread <- ret_from_fork
        6.496096 [003] <idle>                0.003  0.000  0.996
        6.496169 [002] <idle>                0.011  0.000  0.072
        6.496171 [000] ls[520]               0.008  0.000  1.049 do_exit <- do_group_exit <- [unknown]
        6.496172 [003] gnome-terminal-[4391] 0.000  0.003  0.076 schedule_hrtimeout_range_clock <- schedule_hrtimeout_range <- poll_schedule_
        [root@jouet experimental]#
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20161124011114.7102-1-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cdeb01bf
  8. 23 11月, 2016 1 次提交
  9. 15 11月, 2016 1 次提交
  10. 29 9月, 2016 1 次提交
  11. 05 9月, 2016 2 次提交
  12. 30 8月, 2016 2 次提交
  13. 05 7月, 2016 1 次提交
    • H
      perf sdt: ELF support for SDT · 060fa0c7
      Hemant Kumar 提交于
      This patch serves the initial support to identify and list SDT events in
      binaries.  When programs containing SDT markers are compiled, gcc with
      the help of assembler directives identifies them and places them in the
      section ".note.stapsdt".
      
      To find these markers from the binaries, one needs to traverse through
      this section and parse the relevant details like the name, type and
      location of the marker. Also, the original location could be skewed due
      to the effect of prelinking. If that is the case, the locations need to
      be adjusted.
      
      The functions in this patch open a given ELF, find out the SDT section,
      parse the relevant details, adjust the location (if necessary) and
      populate them in a list.
      
      A typical note entry in ".note.stapsdt" section is as follows :
      
                                       |--nhdr.n_namesz--|
                      ------------------------------------
                      |      nhdr      |     "stapsdt"   |
              -----   |----------------------------------|
               |      |  <location>       <base_address> |
               |      |  <semaphore>                     |
      nhdr.n_descsize |  "provider_name"   "note_name"   |
               |      |   <args>                         |
              -----   |----------------------------------|
                      |      nhdr      |     "stapsdt"   |
                      |...
      
      The above shows an excerpt from the section ".note.stapsdt".  'nhdr' is
      a structure which has the note name size (n_namesz), note description
      size (n_desc_sz) and note type (n_type).
      
      So, in order to parse the note note info, we need nhdr to tell us where
      to start from.  As can be seen from <sys/sdt.h>, the name of the SDT
      notes given is "stapsdt".  But this is not the identifier of the note.
      
      After that, we go to description of the note to find out its location, the
      address of the ".stapsdt.base" section and the semaphore address.
      Then, we find the provider name and the SDT marker name and then follow the
      arguments.
      Signed-off-by: NHemant Kumar <hemant@linux.vnet.ibm.com>
      Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/146736022628.27797.1201368329092908163.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      060fa0c7
  14. 23 5月, 2016 1 次提交
    • A
      perf report: Add srcline_from/to branch sort keys · 508be0df
      Andi Kleen 提交于
      Add "srcline_from" and "srcline_to" branch sort keys that allow to show
      the source lines of a branch.
      
      That makes it much easier to track down where particular branches happen
      in the program, for example to examine branch mispredictions, or to
      associate it with cycle counts:
      
        % perf record -b -e cycles:p ./tcall
        % perf report --sort srcline_from,srcline_to,mispredict
        ...
          15.10%  tcall.c:18       tcall.c:10       N
          14.83%  tcall.c:11       tcall.c:5        N
          14.12%  tcall.c:7        tcall.c:12       N
          14.04%  tcall.c:12       tcall.c:5        N
          12.42%  tcall.c:17       tcall.c:18       N
          12.39%  tcall.c:7        tcall.c:13       N
          12.27%  tcall.c:13       tcall.c:17       N
        ...
      
        % perf report --sort srcline_from,srcline_to,cycles
        ...
          17.12%  tcall.c:18       tcall.c:11       1
          17.01%  tcall.c:12       tcall.c:6        1
          16.98%  tcall.c:11       tcall.c:6        1
          15.91%  tcall.c:17       tcall.c:18       1
           6.38%  tcall.c:7        tcall.c:17       7
           4.80%  tcall.c:7        tcall.c:12       8
           4.21%  tcall.c:7        tcall.c:17       8
           2.67%  tcall.c:7        tcall.c:12       7
           2.62%  tcall.c:7        tcall.c:12       10
           2.10%  tcall.c:7        tcall.c:17       9
           1.58%  tcall.c:7        tcall.c:12       6
           1.44%  tcall.c:7        tcall.c:12       5
           1.38%  tcall.c:7        tcall.c:12       9
           1.06%  tcall.c:7        tcall.c:17       13
           1.05%  tcall.c:7        tcall.c:12       4
           1.01%  tcall.c:7        tcall.c:17       6
      
      Open issues:
      
      - Some kernel symbols get misresolved.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Link: http://lkml.kernel.org/r/1463775308-32748-1-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      508be0df
  15. 20 5月, 2016 1 次提交
  16. 17 5月, 2016 1 次提交
  17. 11 5月, 2016 1 次提交
    • C
      perf symbols: Add dso__insert_symbol function · ae93a6c7
      Chris Phlipot 提交于
      The current method for inserting symbols is to use the symbols__insert()
      function. However symbols__insert() does not update the dso symbol
      cache.  This causes problems in the following scenario:
      
      1. symbol not found at addr using dso__find_symbol
      
      2. symbol inserted at addr using the existing symbols__insert function
      
      3. symbol still not found at addr using dso__find_symbol() because cache isn't
         updated. This is undesired behavior.
      
      The undesired behavior in (3) is addressed by creating a new function,
      dso__insert_symbol() to both insert the symbol and update the symbol
      cache if necessary.
      
      If dso__insert_symbol() is used in (2) instead of symbols__insert(),
      then the undesired behavior in (3) is avoided.
      Signed-off-by: NChris Phlipot <cphlipot0@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1462937209-6032-2-git-send-email-cphlipot0@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ae93a6c7
  18. 06 5月, 2016 1 次提交
  19. 19 4月, 2016 1 次提交
  20. 15 4月, 2016 1 次提交
  21. 12 4月, 2016 1 次提交
    • A
      perf evsel: Allow unresolved symbol names to be printed as addresses · fd4be130
      Arnaldo Carvalho de Melo 提交于
      The fprintf_sym() and fprintf_callchain() methods now allow users to
      change the existing behaviour of showing "[unknown]" as the name of
      unresolved symbols to instead show "[0x123456]", i.e. its address.
      
      The current patch doesn't change tools to use this facility, the results
      from 'perf trace' and 'perf script' cotinue like:
      
      70.109 ( 0.001 ms): qemu-system-x8/10153 poll(ufds: 0x7f2d93ffe870, nfds: 1) = 0 Timeout
                                         [unknown] (/usr/lib64/libc-2.22.so)
                                         [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                         [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                         [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                         start_thread+0xca (/usr/lib64/libpthread-2.22.so)
                                         __clone+0x6d (/usr/lib64/libc-2.22.so)
      
      The next patch will make 'perf trace' use the new formatting.
      Suggested-by: NMilian Wolff <milian.wolff@kdab.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-fja1ods5vqpg42mdz09xcz3r@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fd4be130
  22. 24 3月, 2016 1 次提交
  23. 25 2月, 2016 1 次提交
  24. 07 1月, 2016 1 次提交
    • N
      perf report/top: Add --raw-trace option · 053a3989
      Namhyung Kim 提交于
      The --raw-trace option allows disabling pretty printing by the event's
      print_fmt or plugin.  Besides that, each dynamic sort key now can
      receive a 'raw' suffix separated by '/' to ask for the raw trace of a
      specific field.
      
        $ perf report -s comm,kmem:kmalloc.gfp_flags
        ...
        # Overhead  Command            gfp_flags
        # ........  .......  ...................
        #
            99.89%  perf       GFP_NOFS|GFP_ZERO
             0.06%  sleep             GFP_KERNEL
             0.03%  perf     GFP_KERNEL|GFP_ZERO
             0.01%  perf              GFP_KERNEL
      
      Now
      
        $ perf report -s comm,kmem:kmalloc.gfp_flags --raw-trace
      or
        $ perf report -s comm,kmem:kmalloc.gfp_flags/raw
        ...
        # Overhead  Command   gfp_flags
        # ........  .......  ..........
        #
            99.89%  perf          32848
             0.06%  sleep           208
             0.03%  perf          32976
             0.01%  perf            208
      Suggested-and-Acked-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NNamhyung Kim <namhyung@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: Jiri Olsa <jolsa@redhat.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-9-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      053a3989
  25. 27 11月, 2015 1 次提交
  26. 13 11月, 2015 1 次提交
  27. 14 9月, 2015 1 次提交
  28. 29 8月, 2015 1 次提交
  29. 13 8月, 2015 1 次提交
    • K
      perf report: Show call graph from reference events · 9e207ddf
      Kan Liang 提交于
      Introduce --show-ref-call-graph for perf report to print reference
      callgraph for no callgraph event.
      
      Here is an example.
      
       perf report --show-ref-call-graph --stdio
      
       # To display the perf.data header info, please use
       --header/--header-only options.
       #
       #
       # Total Lost Samples: 0
       #
       # Samples: 5  of event 'cpu/cpu-cycles,call-graph=fp/'
       # Event count (approx.): 144985
       #
       # Children      Self  Command  Shared Object     Symbol
       # ........  ........  .......  ................  ........................................
       #
          72.30%     0.00%  sleep    [kernel.vmlinux]  [k] entry_SYSCALL_64_fastpath
                    |
                    ---entry_SYSCALL_64_fastpath
                       |
                       |--22.62%-- __GI___libc_nanosleep
                        --77.38%-- [...]
      
      ......
      
       # Samples: 6  of event 'cpu/instructions,call-graph=no/', show reference callgraph
       # Event count (approx.): 172780
       #
       # Children      Self  Command  Shared Object     Symbol
       # ........  ........  .......  ................  ........................................
       #
          73.16%     0.00%  sleep    [kernel.vmlinux]  [k] entry_SYSCALL_64_fastpath
                    |
                    ---entry_SYSCALL_64_fastpath
                       |
                       |--31.44%-- __GI___libc_nanosleep
                        --68.56%-- [...]
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1439289050-40510-3-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9e207ddf
  30. 13 7月, 2015 1 次提交
    • A
      perf symbols: Store if there is a filter in place · 0bc2f2f7
      Arnaldo Carvalho de Melo 提交于
      When setting yup the symbols library we setup several filter lists,
      for dsos, comms, symbols, etc, and there is code that, if there are
      filters, do certain operations, like recalculate the number of non
      filtered histogram entries in the top/report TUI.
      
      But they were considering just the "Zoom" filters, when they need to
      take into account as well the above mentioned filters (perf top --comms,
      --dsos, etc).
      
      So store in symbol_conf.has_filter true if any of those filters is in
      place.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-f5edfmhq69vfvs1kmikq1wep@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0bc2f2f7
  31. 06 5月, 2015 1 次提交
  32. 04 5月, 2015 3 次提交
  33. 25 3月, 2015 1 次提交
  34. 12 3月, 2015 1 次提交