- 07 Aug, 2013 37 commits
-
-
Arnaldo Carvalho de Melo authored
The previous description: "Search previous string" is usually associated with the 'N' following a '/string', the opposite of 'n', which is 'Search next string' in the direction established with '/' or '?'. So change it to 'Search string backwards', to clarify that. The 'N' hotkey remains to be implemented with the semantic described above. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-5lw5y15d7vv308xbpm8pqe4g@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Adrian Hunter authored
The /proc/kcore file has no symbols, so the call target name does not display. Fix by looking up the symbol name if it is on the same map. Reported-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1375875537-4509-14-git-send-email-adrian.hunter@intel.comSigned-off-by:
-
Adrian Hunter authored
When kcore is used for annotation, symbols do not have correct sizes because they come from kallsyms, that has only its start address, with the end address being the next symbol's minus one. That sometimes results in an extra nop being seen after the end of a function. Remove it. Suggested-by:
-
Adrian Hunter authored
Currently the symbol name is displayed at the top when displaying symbol annotation. Add to this the dso long name. Suggested-by:
-
Adrian Hunter authored
Annotation with /proc/kcore is possible so the logic is adjusted to allow it. The main difference is that /proc/kcore had no symbols so the parsing logic needed a tweak to read jump offsets. The other difference is that objdump cannot always read from kcore. That seems to be a bug with objdump. Signed-off-by:
-
Adrian Hunter authored
Make the "object code reading" test attempt to read from kcore. The test uses objdump which struggles with kcore. i.e. doesn't always work, sometimes takes a long time. The test has been made to work around those issues. Signed-off-by:
-
Adrian Hunter authored
The kallsyms maps now may map to kcore and the symbol values now may be file offsets. For comparison with vmlinux the virtual memory address is needed which is obtained by unmapping the symbol value. The "vmlinux symtab matches kallsyms" is adjusted accordingly. Signed-off-by:
-
Adrian Hunter authored
In the absence of vmlinux, perf tools uses kallsyms for symbols. If the user has access, now also map to /proc/kcore. The dso data_type is now set to either DSO_BINARY_TYPE__KCORE or DSO_BINARY_TYPE__GUEST_KCORE as approprite. This patch breaks the "vmlinux symtab matches kallsyms" test. That is fixed in a following patch. Signed-off-by:
-
Adrian Hunter authored
The new "object code reading" test shows that it is not possible to read object code from kernel modules. That is because the mappings do not map to the dsos. This patch fixes that. This involves identifying and flagging relocatable (ELF type ET_REL) files (e.g. kernel modules) for symbol adjustment and updating map__rip_2objdump() accordingly. The kmodule parameter of dso__load_sym() is taken into use and the module map altered to map to the dso. Signed-off-by:
-
Adrian Hunter authored
The vmlinux maps now map to the dso and the symbol values are now file offsets. For comparison with kallsyms the virtual memory address is needed which is obtained by unmapping the symbol value. The "vmlinux symtab matches kallsyms" is adjusted accordingly. Signed-off-by:
-
Adrian Hunter authored
The new "object code reading" test shows that it is not possible to read object code from vmlinux. That is because the mappings do not map to the dso. This patch fixes that. A side-effect of changing the kernel map is that the "reloc" offset must be taken into account. As a result of that separate map functions for relocation are no longer needed. Also fixing up the maps to match the symbols no longer makes sense and so is not done. The vmlinux dso data_type is now set to either DSO_BINARY_TYPE__VMLINUX or DSO_BINARY_TYPE__GUEST_VMLINUX as approprite, which enables the correct file name to be determined by dso__binary_type_file(). This patch breaks the "vmlinux symtab matches kallsyms" test. That is fixed in a following patch. Signed-off-by:
-
Adrian Hunter authored
In order to use kernel maps to read object code, those maps must be adjusted to map to the dso file offset. Because lazy-initialization is used, that is not done until symbols are loaded. However the maps are first used by thread__find_addr_map() before symbols are loaded. So this patch changes thread__find_addr() to "load" kernel maps before using them. Signed-off-by:
-
Adrian Hunter authored
Using the information in mmap events, perf tools can read object code associated with sampled addresses. A test is added that compares bytes read by perf with the same bytes read using objdump. Signed-off-by:
-
Adrian Hunter authored
When removing duplicate symbols, prefer to remove syscall aliases starting with SyS or compat_SyS. A side-effect of that is that it results in slightly improved results for the "vmlinux symtab matches kallsyms" test. Signed-off-by:
-
Andi Kleen authored
When interval mode is outputting to a pipe, each measurement should be flushed individually, so that the reader sees it timely. With a terminal each line is automatically flushed by stdio, but that is disabled with non terminal output. Simply fflush output after each time interval Signed-off-by:
Andi Kleen <ak@linux.intel.com> Reviewed-by:
Jiri Olsa <jolsa@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1375490473-1503-5-git-send-email-andi@firstfloor.orgSigned-off-by:
-
Andi Kleen authored
When measuring workloads the startup phase -- doing page faults, dynamic linking, opening files -- is often very different from the rest of the workload. Especially with smaller kernels and using counter multiplexing this can give significant measurement errors. Multiplexing assumes that the workload is mostly the same over longer periods. But at startup there is typically some spike of activity which is relatively short. If many groups are multiplexing the one group seeing the spike, and which is then scaled up over the time to run all groups, may see a significant error. Also in general it's often not useful to measure the startup, because it is so different from the rest. One way around this is to use interval mode and discard the first sample, but this can be awkward because interval mode doesn't support intervals of less than 100ms, and also a useful interval is not necessarily the same as a useful startup delay. This patch adds a new --initial-delay / -D option to skip measuring for the startup phase. The time can be specified in ms Here's a simple example: perf stat -e page-faults bash -c 'for i in $(seq 100000) ; do true ; done' ... 3,721 page-faults ... If we just wait 20 ms the number of page faults is 1/3 less: perf stat -D 20 -e page-faults bash -c 'for i in $(seq 100000) ; do true ; done' ... 2,823 page-faults ... So we filtered out most of the startup noise from bash. Signed-off-by: -
Andi Kleen authored
Add support for enabling already set up counters by using an ioctl. I share some code with the filter setup. Signed-off-by:
-
Andi Kleen authored
Minor cleanup. The dummy execve to pre-resolve the PLT is obsolete since "enable_on_execve" was added. The counters are only running after the execve anyways. So just remove it. Signed-off-by:
-
David Ahern authored
Needed by kvm live command. Make record_args a local while we are messing with the args. Signed-off-by:
David Ahern <dsahern@gmail.com> Reviewed-by:
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Runzhen Wang <runzhen@linux.vnet.ibm.com> Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1375473947-64285-5-git-send-email-dsahern@gmail.comSigned-off-by:
-
David Ahern authored
Allows kvm live mode to reuse the event processing and ordered samples processing used by the perf-report path. v2: removed flush_sample_queue as noticed by Jiri Signed-off-by:
-
David Ahern authored
Need an initialization function to set min to -1 to differentiate from an actual min of 0. Signed-off-by:
-
David Ahern authored
For use with kvm-live mode. Signed-off-by:
-
Namhyung Kim authored
The parse_nsec_time() function is for parsing a string of time into 64-bit nsec value. It's a preparation of time filtering in some of perf commands. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Arnaldo Carvalho de Melo authored
Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thiago Peixoto <thiagolcpeixoto@gmail.com> Link: http://lkml.kernel.org/n/tip-jurgz6myq125o1ql6lldh6f7@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
It is an errno, so print an error string. Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-zt68gijvvoe8gd7kmclo43si@git.kernel.orgSigned-off-by:
-
David Ahern authored
On Fedora 18, with gcc 4.6.4 compile fails with: arch/x86/util/tsc.c: In function ‘perf_time_to_tsc’: arch/x86/util/tsc.c:13:6: error: declaration of ‘time’ shadows a global declaration [-Werror=shadow] cc1: all warnings being treated as errors make: *** [/tmp/junk/arch/x86/util/tsc.o] Error 1 make: *** Waiting for unfinished jobs.... Fix by renaming the local variable. Signed-off-by:
-
David Ahern authored
Symbol offset is one of the fields that can be requested in perf-script. Currently you do not get that data when requested. e.g., perf script -f comm,tid,pid,time,cpu,sym,symoff,ip ... gcc 6201/6201 [006] 762250.617897: ffffffff81090d95 update_curr ffffffff810911b8 dequeue_entity ffffffff81091825 dequeue_task_fair ffffffff81087163 dequeue_task ffffffff81087c03 deactivate_task ... With this patch you get the offset: ... gcc 6201/6201 [006] 762250.617897: ffffffff81090d95 update_curr+0x1c5 ffffffff810911b8 dequeue_entity+0x28 ffffffff81091825 dequeue_task_fair+0x45 ffffffff81087163 dequeue_task+0x93 ffffffff81087c03 deactivate_task+0x23 ... Signed-off-by: -
Jiri Olsa authored
Adding 2 more tests to the automated parse events suite for following event config: '{cycles,cache-misses,branch-misses}:S' '{instructions,branch-misses}:Su' Signed-off-by: -
Jiri Olsa authored
Adding test to validate perf_event_attr data for command: 'record -e '{cycles,cache-misses}:S' Signed-off-by: -
Jiri Olsa authored
Adding 'S' event/group modifier to specify that the event value/s are read by PERF_SAMPLE_READ sample type processing, instead of the period value offered by lower layers. There's additional behaviour change for 'S' modifier being specified on event group: Currently all the events within a group makes samples. If user now specifies 'S' within group modifier, only the leader will trigger samples. The rest of events in the group will have sampling disabled. And same as for single events, values of all events within the group (including leader) are read by PERF_SAMPLE_READ sample type processing. Following example will create event group with cycles and cache-misses events, setting the cycles as group leader and the only event to actually sample. Both cycles and cache-misses event period values are read by PERF_SAMPLE_READ sample type processing with PERF_FORMAT_GROUP read format. Example: $ perf record -e '{cycles,cache-misses}:S' ls ... $ perf report --group --show-total-period --stdio ... # Samples: 36 of event 'anon group { cycles, cache-misses }' # Event count (approx.): 12585593 # # Overhead Period Command Shared Object Symbol # .............. .............. ....... ................. .......................... # 19.92% 1.20% 2505936 31 ls [kernel.kallsyms] [k] mark_held_locks 13.74% 0.47% 1729327 12 ls [kernel.kallsyms] [k] sched_clock_local 13.64% 23.72% 1716147 612 ls ld-2.14.90.so [.] check_match.10805 13.12% 23.22% 1650778 599 ls libc-2.14.90.so [.] _nl_intern_locale_data 11.24% 29.19% 1414554 753 ls [kernel.kallsyms] [k] sched_clock_cpu 8.50% 0.35% 1070150 9 ls [kernel.kallsyms] [k] check_chain_key ... Signed-off-by: -
Jiri Olsa authored
For sample with sample type PERF_SAMPLE_READ the period value is stored in the 'struct sample_read'. Moreover if the read format has PERF_FORMAT_GROUP, the 'struct sample_read' contains period values for all events in the group (for which the sample's event is a leader). We deliver separated samples for all the values contained within the 'struct sample_read'. Signed-off-by:
-
Jiri Olsa authored
This will be helpful for PERF_FORMAT_GROUP samples where we need to store ID related period value for each event. Signed-off-by:
-
Jiri Olsa authored
We need to fail the event ID retrieval in case both following conditions are true: - we are on kernel with no PERF_EVENT_IOC_ID support - PERF_FORMAT_GROUP read format is set The PERF_FORMAT_GROUP read format bit is the killer for retrieving event ID out of the read syscall, because we have no guarantee of the event placement within leader kernel sibling list. Signed-off-by:
-
Jiri Olsa authored
Adding support to parse out the PERF_SAMPLE_READ sample bits. The code contains both single and group format specification. This code parse out and prepare PERF_SAMPLE_READ data into the perf_sample struct. It will be used for group leader sampling feature comming in shortly. Signed-off-by:
-
Jiri Olsa authored
Changing the way we retrieve the event ID. Instead of parsing out the ID out of the read data, using the PERF_EVENT_IOC_ID ioctl. Keeping the old way in place to support kernels without PERF_EVENT_IOC_ID ioctl support. This will be useful for retrieving the event ID for events with PERF_FORMAT_GROUP read format set, where it's impossible to get correct event id out of the read call data. Signed-off-by:
-
Jiri Olsa authored
It's possible some of the counters in the group could be disabled when sampling member of the event group is reading the rest via PERF_SAMPLE_READ sample type processing. Disabled counters could then produce wrong numbers. Fixing that by reading only enabled counters for PERF_SAMPLE_READ sample type processing. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-wwkjb0bbcuslnz0klrmqi26r@git.kernel.orgSigned-off-by:
-
Jiri Olsa authored
The only way to get the event ID is by reading the event fd, followed by parsing the ID value out of the returned data. While this is ok for current read format used by perf tool, it is not ok when we use PERF_FORMAT_GROUP format. With this format the data are returned for the whole group and there's no way to find out what ID belongs to our fd (if we are not group leader event). Adding a simple ioctl that returns event primary ID for given fd. Signed-off-by:
-
- 30 Jul, 2013 3 commits
-
-
Frederic Weisbecker authored
A perf event can be used without forcing the tick to stay alive if it doesn't use a frequency but a sample period and if it doesn't throttle (raise storm of events). Since the lockup detector neither use a perf event frequency nor should ever throttle due to its high period, it can now run concurrently with the full dynticks feature. So remove the hack that disabled the watchdog. Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Stephane Eranian <eranian@google.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: Anish Singh <anish198519851985@gmail.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1374539466-4799-9-git-send-email-fweisbec@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Frederic Weisbecker authored
Currently the full dynticks subsystem keep the tick alive as long as there are perf events running. This prevents the tick from being stopped as long as features such that the lockup detectors are running. As a temporary fix, the lockup detector is disabled by default when full dynticks is built but this is not a long term viable solution. To fix this, only keep the tick alive when an event configured with a frequency rather than a period is running on the CPU, or when an event throttles on the CPU. These are the only purposes of the perf tick, especially now that the rotation of flexible events is handled from a seperate hrtimer. The tick can be shutdown the rest of the time. Original-patch-by:
-
Frederic Weisbecker authored
This is going to be used by the full dynticks subsystem as a finer-grained information to know when to keep and when to stop the tick. Original-patch-by:
-
