- 08 Mar, 2018 35 commits
-
-
Thomas Richter authored
S390 has several load and store instructions with target operand addressing relative to the program counter, for example lrl, lgrl, strl, stgrl. These instructions are handled similar to x86. Objdump output displays those instructions as: 9595c: c4 2d 00 09 9c 54 lgrl %r7,1c8540 <mp_+0x60> This output is parsed (like on x86) and perf annotate shows those lines as: lgrl %r7,mp_+0x60 This patch handles the s390 specific instruction parsing for PC relative load and store instructions. Signed-off-by:
Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20180308120913.14802-1-tmricht@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jin Yao authored
Unlike the perf report interactive annotate mode, the perf annotate doesn't display the IPC/Cycle even if branch info is recorded in perf data file. perf record -b ... perf annotate function It should show IPC/cycle, but it doesn't. This patch lets perf annotate support the displaying of IPC/Cycle if branch info is in perf data. For example, perf annotate compute_flag Percent│ IPC Cycle │ │ │ Disassembly of section .text: │ │ 0000000000400640 <compute_flag>: │ compute_flag(): │ volatile int count; │ static unsigned int s_randseed; │ │ __attribute__((noinline)) │ int compute_flag() │ { 22.96 │1.18 584 sub $0x8,%rsp │ int i; │ │ i = rand() % 2; 23.02 │1.18 1 → callq rand@plt │ │ return i; 27.05 │3.37 mov %eax,%edx │ } │3.37 add $0x8,%rsp │ { │ int i; │ │ i = rand() % 2; │ │ return i; │3.37 shr $0x1f,%edx │3.37 add %edx,%eax │3.37 and $0x1,%eax │3.37 sub %edx,%eax │ } 26.97 │3.37 2 ← retq Note that, this patch only supports TUI mode. For stdio, now it just keeps original behavior. Will support it in a follow-up patch. $ perf annotate compute_flag --stdio Percent | Source code & Disassembly of div for cycles:ppp (7993 samples) ------------------------------------------------------------------------------ : : : : Disassembly of section .text: : : 0000000000400640 <compute_flag>: : compute_flag(): : volatile int count; : static unsigned int s_randseed; : : __attribute__((noinline)) : int compute_flag() : { 0.29 : 400640: sub $0x8,%rsp # +100.00% : int i; : : i = rand() % 2; 42.93 : 400644: callq 400490 <rand@plt> # -100.00% (p:100.00%) : : return i; 0.10 : 400649: mov %eax,%edx # +100.00% : } 0.94 : 40064b: add $0x8,%rsp : { : int i; : : i = rand() % 2; : : return i; 27.02 : 40064f: shr $0x1f,%edx 0.15 : 400652: add %edx,%eax 1.24 : 400654: and $0x1,%eax 2.08 : 400657: sub %edx,%eax : } 25.26 : 400659: retq # -100.00% (p:100.00%) Signed-off-by:Jin Yao <yao.jin@linux.intel.com> Acked-by:
Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/20180223170210.GC7045@tassilo.jf.intel.com Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1519724327-7773-1-git-send-email-yao.jin@linux.intel.comSigned-off-by:
-
Wang YanQing authored
So that beautifiers wanting to resolve kernel function addresses to names can do its work, and when we use "perf report" for output of "perf kmem record", we will get kernel symbol output. This patch affect the output of "perf report" for the record data generated by "perf kmem record" looks like below: Before patch: 0.01% call_site=ffffffff814e5828 ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC 0.01% call_site=ffffffff81370b87 ptr=0x428a3060 bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO After patch: 0.01% (aa_alloc_task_context+0x27) call_site=ffffffff81370b87 ptr=0x428a3060 bytes_req=32 bytes_alloc=32 gfp_flags=GFP_KERNEL|GFP_ZERO 0.01% (__tty_buffer_request_room+0x88) call_site=ffffffff814e5828 ptr=0x99bb000 bytes_req=3616 bytes_alloc=4096 gfp_flags=GFP_ATOMIC Signed-off-by:
Wang YanQing <udknight@gmail.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Tested-by:
-
Jiri Olsa authored
So we can see the output of feature compile in following files: tools/build/feature/test-llvm.make.output tools/build/feature/test-llvm-version.make.output tools/build/feature/test-clang.make.output Signed-off-by:
-
Jiri Olsa authored
So they can follow the OUTPUT variable setup as the rest of the features. Signed-off-by:
-
Jiri Olsa authored
So we can see the status when we build perf, like: $ make LIBCLANGLLVM=1 VF=1 ... cxx: [ on ] ... llvm: [ on ] ... llvm-version: [ on ] ... clang: [ on ] Signed-off-by:
-
Jiri Olsa authored
We have some .cpp files, make ctags/cscope aware of them. Signed-off-by:
-
Jiri Olsa authored
Adding MEM_TOPOLOGY feature to perf data file, that will carry physical memory map and its node assignments. The format of data in MEM_TOPOLOGY is as follows: 0 - version | for future changes 8 - block_size_bytes | /sys/devices/system/memory/block_size_bytes 16 - count | number of nodes For each node we store map of physical indexes for each node: 32 - node id | node index 40 - size | size of bitmap 48 - bitmap | bitmap of memory indexes that belongs to node | /sys/devices/system/node/node<NODE>/memory<INDEX> The MEM_TOPOLOGY could be displayed with following report command: $ perf report --header-only -I ... # memory nodes (nr 1, block size 0x8000000): # 0 [7G]: 0-23,32-69 Signed-off-by: -
Jiri Olsa authored
Switch to refcnt logic instead of duplicating mem_info objects. No functional change, just saving some memory. Signed-off-by:
-
Jiri Olsa authored
It's passed along several hists entries in --hierarchy mode, so it's better we keep track of it. The current fail I see is that it gets removed in hierarchy --mem-mode mode, where it's shared in the different hierarchies, but removed from the template hist entry, so the report crashes. Signed-off-by:
-
Jiri Olsa authored
It's no longer used. Signed-off-by:
-
Jiri Olsa authored
It's used far more down to be declared on the top of the __cmd_record. Signed-off-by:
-
Jiri Olsa authored
Display more header info from perf.data file, following values: $ perf report -i perf.data --header-only ... # header version : 1 # data offset : 424 # data size : 3364280 # feat offset : 3364704 It's handy for debuging. Signed-off-by:
-
Jiri Olsa authored
Changing the output header for reporting forced groups via --groups option on non grouped events, like: $ perf record -e 'cycles,instructions' $ perf report --stdio --group Before: # Samples: 24 of event 'anon group { cycles:u, instructions:u }' After: # Samples: 24 of events 'cycles:u, instructions:u' Signed-off-by: -
Thomas Richter authored
'perf annotate' displays function call assembler instructions with a right arrow. Hitting enter on this line/instruction causes the browser to disassemble this target function and show it on the screen. On s390 this results in an error message 'The called function was not found.' The function call assembly line parsing does not handle the s390 bras and brasl instructions. Function call__parse expects the target as first operand: callq e9140 <__fxstat> S390 has a register number as first operand: brasl %r14,41d60 <abort> Therefore the target addresses on s390 are always zero which is an invalid address. Introduce a s390 specific call parsing function which skips the first operand on s390. Signed-off-by:
-
Adrian Hunter authored
Adjust overlap-checking to support sampling mode. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/1520431349-30689-10-git-send-email-adrian.hunter@intel.comSigned-off-by:
-
Adrian Hunter authored
Intel PT code already has some preparation for AUX area sampling mode. However the implementation has changed from the first proposal and one of the side-effects is that it will not be impossible to support snapshot mode and sampling mode at the same time. Although there are no plans to support it, let validation (not yet implemented) control whether it is allowed rather than low-level functions. Signed-off-by:
-
Adrian Hunter authored
intel_pt_get_trace() fixes overlaps between the current buffer and the previous buffer ('old_buffer'). However the previous buffer might not have had usable data (no PSB) so the comparison must be made against the previous buffer that had usable data. Tidy that by keeping a pointer for that purpose in struct intel_pt_queue. Signed-off-by: -
Adrian Hunter authored
With the new way sampling support will be implemented, intel_pt_use_buffer_pid_tid() will not be needed. Get rid of it. Signed-off-by:
-
Adrian Hunter authored
Tidy auxtrace_record__init_intel() slightly by recognizing that evlist is never NULL. Signed-off-by:
-
Adrian Hunter authored
timestamp_insn_cnt is used to estimate the timestamp based on the number of instructions since the last known timestamp. If the estimate is not accurate enough decoding might not be correctly synchronized with side-band events causing more trace errors. However there are always timestamps following an overflow, so the estimate is not needed and can indeed result in more errors. Suppress the estimate by setting timestamp_insn_cnt to zero. Signed-off-by:
-
Adrian Hunter authored
When a TIP packet is expected but there is a different packet, it is an error. However the unexpected packet might be something important like a TSC packet, so after the error, it is necessary to continue from there, rather than the next packet. That is achieved by setting pkt_step to zero. Signed-off-by:
-
Adrian Hunter authored
sync_switch is a facility to synchronize decoding more closely with the point in the kernel when the context actually switched. The flag when sync_switch is enabled was global to the decoding, whereas it is really specific to the CPU. The trace data for different CPUs is put on different queues, so add sync_switch to the intel_pt_queue structure and use that in preference to the global setting in the intel_pt structure. That fixes problems decoding one CPU's trace because sync_switch was disabled on a different CPU's queue. Signed-off-by:
-
Adrian Hunter authored
Overlap detection was not not updating the buffer's 'consecutive' flag. Marking buffers consecutive has the advantage that decoding begins from the start of the buffer instead of the first PSB. Fix overlap detection to identify consecutive buffers correctly. Signed-off-by:
-
Kan Liang authored
It isn't necessary to pass the 'start', 'end' and 'overwrite' arguments to perf_mmap__read_init(). The data is stored in the struct perf_mmap. Discard the parameters. Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Suggested-by:
-
Kan Liang authored
It isn't necessary to pass the 'overwrite', 'start' and 'end' argument to perf_mmap__read_event(). Discard them. Signed-off-by:
-
Kan Liang authored
It isn't necessary to pass the 'overwrite' argument to perf_mmap__consume(). Discard it. Signed-off-by:
-
Kan Liang authored
The 'overwrite' is set at allocation. It will not be changed. Using it to replace the parameter of perf_mmap__consume(). The parameters will be discarded later. No functional change. Signed-off-by:
-
Kan Liang authored
Using the 'start', 'end' and 'overwrite' which are stored in struct perf_mmap to replace the parameters of perf_mmap__read_event(). The parameters will be discarded later. No functional change. Signed-off-by:
-
Kan Liang authored
Using the 'start' and 'end' which are stored in struct perf_mmap to replace the temporary 'start' and 'end'. The temporary variables will be discarded later. It doesn't need to pass 'overwrite' to perf_mmap__push(). It's stored in struct perf_mmap. Signed-off-by:
-
Kan Liang authored
There is too much boilerplate in the perf_mmap__read*() interfaces. The 'start' and 'end' variables should be stored in struct perf_mmap at initialization. They will be used later. The old 'startp' and 'endp' pointers are used by perf_mmap__read_event() now. They cannot be removed. So the old 'startp/endp' and new 'md->start/md->end' will exist simultaneously now. The old one will be removed later. Signed-off-by:
-
Kan Liang authored
It has been determined that the map is for overwrite mode (evlist->overwrite_mmap) or non-overwrite mode (evlist->mmap) when calling perf_evlist__alloc_mmap(). Store the information in struct perf_mmap, which will be used later to simplify the perf_mmap__read*() interfaces. Signed-off-by:
-
Agustin Vega-Frias authored
Auto-merge for these events was disabled when auto-merging of non-alias events was disabled in commit 63ce8449 (perf stat: Only auto-merge events that are PMU aliases). Non-merging of legacy events is preserved: $ perf stat -ag -e cache-misses,cache-misses sleep 1 Performance counter stats for 'system wide': 86,323 cache-misses 86,323 cache-misses 1.002623307 seconds time elapsed But prefix or glob matching auto-merges the events created: $ perf stat -a -e l3cache/read-miss/ sleep 1 Performance counter stats for 'system wide': 328 l3cache/read-miss/ 1.002627008 seconds time elapsed $ perf stat -a -e l3cache_0_[01]/read-miss/ sleep 1 Performance counter stats for 'system wide': 172 l3cache/read-miss/ 1.002627008 seconds time elapsed As with events created with aliases, auto-merging can be suppressed with the --no-merge option: $ perf stat -a -e l3cache/read-miss/ --no-merge sleep 1 Performance counter stats for 'system wide': 67 l3cache/read-miss/ 67 l3cache/read-miss/ 63 l3cache/read-miss/ 60 l3cache/read-miss/ 1.002622192 seconds time elapsed Signed-off-by:
Agustin Vega-Frias <agustinv@codeaurora.org> Acked-by:
-
Agustin Vega-Frias authored
To simplify creation of events accross multiple instances of the same type of PMU stat supports two methods for creating multiple events from a single event specification: 1. A prefix or glob can be used in the PMU name. 2. Aliases, which are listed immediately after the Kernel PMU events by perf list, are used. When the --no-merge option is passed and these events are displayed individually the PMU name is lost and it's not possible to see which count corresponds to which pmu: $ perf stat -a -e l3cache/read-miss/ --no-merge ls > /dev/null Performance counter stats for 'system wide': 67 l3cache/read-miss/ 67 l3cache/read-miss/ 63 l3cache/read-miss/ 60 l3cache/read-miss/ 0.001675706 seconds time elapsed $ perf stat -a -e l3cache_read_miss --no-merge ls > /dev/null Performance counter stats for 'system wide': 12 l3cache_read_miss 17 l3cache_read_miss 10 l3cache_read_miss 8 l3cache_read_miss 0.001661305 seconds time elapsed This change adds the original pmu name to the event. For dynamic pmu events the pmu name is restored in the event name: $ perf stat -a -e l3cache/read-miss/ --no-merge ls > /dev/null Performance counter stats for 'system wide': 63 l3cache_0_3/read-miss/ 74 l3cache_0_1/read-miss/ 64 l3cache_0_2/read-miss/ 74 l3cache_0_0/read-miss/ 0.001675706 seconds time elapsed For alias events the name is added after the event name: $ perf stat -a -e l3cache_read_miss --no-merge ls > /dev/null Performance counter stats for 'system wide': 10 l3cache_read_miss [l3cache_0_3] 12 l3cache_read_miss [l3cache_0_1] 10 l3cache_read_miss [l3cache_0_2] 17 l3cache_read_miss [l3cache_0_0] 0.001661305 seconds time elapsed Signed-off-by: -
Agustin Vega-Frias authored
Starting on v4.12 event parsing code for dynamic pmu events already supports prefix-based matching of multiple pmus when creating dynamic events. E.g., in a system with the following dynamic pmus: mypmu_0 mypmu_1 mypmu_2 mypmu_4 passing mypmu/<config>/ as an event spec will result in the creation of the event in all of the pmus. This change expands this matching through the use of fnmatch so glob-like expressions can be used to create events in multiple pmus. E.g., in the system described above if a user only wants to create the event in mypmu_0 and mypmu_1, mypmu_[01]/<config>/ can be passed. Signed-off-by:
-
- 07 Mar, 2018 5 commits
-
-
Takashi Iwai authored
I've tested to process the perf man pages with asciidoctor that is picker than asciidoc, and it revealed minor syntax errors in some documents. Namely, the title markers aren't aligned with the previous line, hence asciidoctor didn't recognize as titles. This patch corrects these markers to be processed properly. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180307105441.28512-1-tiwai@suse.deSigned-off-by:
-
Adrian Hunter authored
In preparation for supporting AUX area sampling buffers, auxtrace_queues__add_buffer() needs to be more generic. To that end, make it return buffer_ptr instead of the caller. Signed-off-by:
-
Adrian Hunter authored
Rename some buffer-queuing functions in preparation for supporting AUX area sampling buffers. Signed-off-by:
-
Adrian Hunter authored
Add missing parameters from kernel-doc comments. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
One can set a cgroup as a default cgroup to be used by all events or set cgroups with the 'perf stat' and 'perf record' behaviour, i.e. '-G A' will be the cgroup for events defined so far in the command line. Here in my main machine, with a kvm instance running a rhel6 guinea pig I have: # ls -la /sys/fs/cgroup/perf_event/ | grep drw drwxr-xr-x. 14 root root 360 Mar 6 12:04 .. drwxr-xr-x. 3 root root 0 Mar 6 15:05 machine.slice # So I can go ahead and use that cgroup hierarchy, say lets see what syscalls are being emitted by threads in that 'machine.slice' hierarchy that are taking more than 100ms: # perf trace --duration 100 -G machine.slice 0.188 (249.850 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 250.274 (249.743 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 500.224 (249.755 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 750.097 (249.934 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 1000.244 (249.780 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 1250.197 (249.796 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 1500.124 (249.859 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 1750.076 (172.900 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 902.570 (1021.116 ms): qemu-system-x8/23667 ppoll(ufds: 0x558151e03180, nfds: 74, tsp: 0x7ffc00cd0900, sigsetsize: 8) = 1 1923.825 (305.133 ms): qemu-system-x8/23667 ppoll(ufds: 0x558151e03180, nfds: 74, tsp: 0x7ffc00cd0900, sigsetsize: 8) = 1 2000.172 (229.002 ms): CPU 0/KVM/23744 ioctl(fd: 16<anon_inode:kvm-vcpu:0>, cmd: KVM_RUN) = 0 ^C # If we look inside that cgroup hierarchy we get: # ls -la /sys/fs/cgroup/perf_event/machine.slice/ | grep drw drwxr-xr-x. 3 root root 0 Mar 6 15:05 . drwxr-xr-x. 2 root root 0 Mar 6 16:16 machine-qemu\x2d2\x2drhel6.sandy.scope # There is just one, but lets say there were more and we would want to see 5 seconds worth of syscall summary for the threads in that cgroup: # perf trace --summary -G machine.slice/machine-qemu\\x2d2\\x2drhel6.sandy.scope/ -a sleep 5 Summary of events: qemu-system-x86 (23667), 143858 events, 24.2% syscall calls total min avg max stddev (msec) (msec) (msec) (msec) (%) --------------- -------- --------- --------- --------- --------- ------ ppoll 28492 4348.631 0.000 0.153 11.616 1.05% futex 19661 140.801 0.001 0.007 2.993 3.20% read 18440 68.084 0.001 0.004 1.653 4.33% ioctl 5387 24.768 0.002 0.005 0.134 1.62% CPU 0/KVM (23744), 449455 events, 75.8% syscall calls total min avg max stddev (msec) (msec) (msec) (msec) (%) --------------- -------- --------- --------- --------- --------- ------ ioctl 148364 3401.812 0.000 0.023 11.801 1.15% futex 36131 404.127 0.001 0.011 7.377 2.63% writev 29452 339.688 0.003 0.012 1.740 1.36% write 11315 45.992 0.001 0.004 0.105 1.10% # See the documentation about how to set more than one cgroup for different events in the same command line. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Richter <tmricht@linux.vnet.ibm.com> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-t126jh4occqvu0xdqlcjygex@git.kernel.orgSigned-off-by:
-
