- 12 Jun, 2014 1 commit
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/core Pull perf/core improvements and fixes from Jiri Olsa: * Bitmask handling and plugin updates (Steven Rostedt) * Fix pipe check regression in attr event callback (Jiri Olsa) * Prettify the tags/TAGS/cscope targets output (Jiri Olsa) * Print array argument as string (Namhyung Kim) * Pass protection and flags bits through mmap2 interface (Peter Zijlstra) * Update perf tool mmap2 interface with protection and flag bits (Don Zickus) * Re-enable mmap interface (Don Zickus) * Add mem-mode documentation to report command (Don Zickus) * Add sort on dcacheline (Don Zickus) Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 09 Jun, 2014 10 commits
-
-
Don Zickus authored
In perf's 'mem-mode', one can get access to a whole bunch of details specific to a particular sample instruction. A bunch of those details relate to the data address. One interesting thing you can do with data addresses is to convert them into a unique cacheline they belong too. Organizing these data cachelines into similar groups and sorting them can reveal cache contention. This patch creates an alogorithm based on various sample details that can help group entries together into data cachelines and allows 'perf report' to sort on it. The algorithm relies on having proper mmap2 support in the kernel to help determine if the memory map the data address belongs to is private to a pid or globally shared. The alogortithm is as follows: o group cpumodes together o group entries with discovered maps together o sort on major, minor, inode and inode generation numbers o if userspace anon, then sort on pid o sort on cachelines based on data addresses The 'dcacheline' sort option in 'perf report' only works in 'mem-mode'. Sample output: # # Samples: 206 of event 'cpu/mem-loads/pp' # Total weight : 2534 # Sort order : dcacheline,pid # # Overhead Samples Data Cacheline Command: Pid # ........ ............ ...................................................................... .................. # 13.22% 1 [k] 0xffff88042f08ebc0 swapper: 0 9.27% 1 [k] 0xffff88082e8cea80 swapper: 0 3.59% 2 [k] 0xffffffff819ba180 swapper: 0 0.32% 1 [k] arch_trigger_all_cpu_backtrace_handler_na.23901+0xffffffffffffffe0 swapper: 0 0.32% 1 [k] timekeeper_seq+0xfffffffffffffff8 swapper: 0 Note: Added a '+1' to symlen size in hists__calc_col_len to prevent the next column from prematurely tabbing over and mis-aligning. Not sure what the problem is. Signed-off-by:Don Zickus <dzickus@redhat.com> Link: http://lkml.kernel.org/r/1401208087-181977-8-git-send-email-dzickus@redhat.comSigned-off-by:
-
Don Zickus authored
Different arches may have different cacheline sizes. Look it up and set a global variable for reference. Signed-off-by:
-
Don Zickus authored
The next patch needs to sort on cpumode, so add it to hist_entry to be tracked. Signed-off-by:
-
Don Zickus authored
Add mem-mode sorting types and mem-mode itself to perf-report documentation. Signed-off-by:
-
Don Zickus authored
This reverts commit 3090ffb5. Re-enable the mmap2 interface as we will have a user soon. Since things have changed since perf disabled mmap2, small tweaks to the revert had to be done: o commit 9d4ecc88 forced (n!=8) to become (n<7) o a new libunwind test needed updating to use mmap2 interface Signed-off-by:
-
Don Zickus authored
The kernel piece passes more info now. Update the perf tool to reflect that and adjust the synthesized maps to play along. Signed-off-by:
-
Peter Zijlstra authored
The mmap2 interface was missing the protection and flags bits needed to accurately determine if a mmap memory area was shared or private and if it was readable or not. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> [tweaked patch to compile and wrote changelog] Signed-off-by:
-
Namhyung Kim authored
With the Sebastian's change of handling num array argument (of raw syscall enter), the script still failed to work like this: $ perf record -e raw_syscalls:* sleep 1 $ perf script -g python $ perf script -s perf-script.py ... Traceback (most recent call last): File "perf-script.py", line 42, in raw_syscalls__sys_enter (id, args), TypeError: %u format: a number is required, not list Fatal Python error: problem in Python trace event handler Aborted (core dumped) This is because the generated script tries to print the array arg as unsigned integer (%u). Since the python seems to convert arguments to strings by default, just using %s solved the problem for me. Signed-off-by:Namhyung Kim <namhyung@kernel.org> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/1401338695-18837-1-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Jiri Olsa authored
Add tags/TAGS/cscope targets to the quiet family. $ make tags cscope BUILD: Doing 'make -j4' parallel build GEN tags $ make cscope BUILD: Doing 'make -j4' parallel build GEN cscope Reviewed-by:
David Ahern <dsahern@gmail.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jean Pihet <jean.pihet@linaro.org> 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/r/1401893676-32205-1-git-send-email-jolsa@kernel.orgSigned-off-by:
-
Jiri Olsa authored
The file factoring in builtin-inject.c object introduced regression in attr event callback. The commit is: 3406912c perf inject: Handle output file via perf_data_file object Following hunk reversed the logic: - if (!inject->pipe_output) + if (&inject->output.is_pipe) putting it back, following example now works: $ perf record -o - kill | perf inject -b | perf report -i - Plus removing extra '&' (kudos to Arnaldo) Reported-by:
Stephane Eranian <eranian@google.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> 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/r/20140605204117.GA1771@krava.redhat.comSigned-off-by:
-
- 07 Jun, 2014 4 commits
-
-
Steven Rostedt (Red Hat) authored
Coming in v3.16, trace events will be able to save bitmasks in raw format in the ring buffer and output it with the __get_bitmask() macro. In order for userspace tools to parse this, it must be able to handle the __get_bitmask() call and be able to convert the data that's in the ring buffer into a nice bitmask format. The output is similar to what the kernel uses to print bitmasks, with a comma separator every 4 bytes (8 characters). This allows for cpumasks to also be saved efficiently. The first user is the thermal:thermal_power_limit event which has the following output: thermal_power_limit: cpus=0000000f freq=1900000 cdev_state=0 power=5252 Link: http://lkml.kernel.org/r/20140506132238.22e136d1@gandalf.local.homeSuggested-by:
Javi Merino <javi.merino@arm.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Acked-by:
-
Steven Rostedt (Red Hat) authored
Add the options "parent" and "indent" to the function plugin. When parent is set, the output looks like this: function: fsnotify_modify <-- vfs_write function: zone_statistics <-- get_page_from_freelist function: __inc_zone_state <-- zone_statistics function: inotify_inode_queue_event <-- fsnotify_modify function: fsnotify_parent <-- fsnotify_modify function: __inc_zone_state <-- zone_statistics function: __fsnotify_parent <-- fsnotify_parent function: inotify_dentry_parent_queue_event <-- fsnotify_parent function: add_to_page_cache_lru <-- do_read_cache_page When it's not set, it looks like: function: fsnotify_modify function: zone_statistics function: __inc_zone_state function: inotify_inode_queue_event function: fsnotify_parent function: __inc_zone_state function: __fsnotify_parent function: inotify_dentry_parent_queue_event function: add_to_page_cache_lru When the otpion "indent" is not set, it looks like this: function: fsnotify_modify <-- vfs_write function: zone_statistics <-- get_page_from_freelist function: __inc_zone_state <-- zone_statistics function: inotify_inode_queue_event <-- fsnotify_modify function: fsnotify_parent <-- fsnotify_modify function: __inc_zone_state <-- zone_statistics function: __fsnotify_parent <-- fsnotify_parent function: inotify_dentry_parent_queue_event <-- fsnotify_parent function: add_to_page_cache_lru <-- do_read_cache_page Signed-off-by:
-
Steven Rostedt authored
The traceevent plugins allows developers to have their events print out information that is more advanced than what can be achieved by the trace event format files. As these plugins are used on the userspace side of the tracing tools, it is only logical that the tools should be able to produce different types of output for the events. The types of events still need to be defined by the plugins thus we need a way to pass information from the tool to the plugin to specify what type of information to be shown. Not only does the information need to be passed by the tool to plugin, but the plugin also requires a way to notify the tool of what options it can provide. This builds the plugin option infrastructure that is taken from trace-cmd that is used to allow plugins to produce different output based on the options specified by the tool. Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Add a flag to pevent that will let the callers be able to set it and keep the system, and perhaps even normal plugins from being loaded. This is useful when plugins might hide certain information and seeing the raw events shows what may be going on. Signed-off-by:
-
- 06 Jun, 2014 3 commits
-
-
Adrian Hunter authored
perf tools like 'perf report' can aggregate samples by comm strings, which generally works. However, there are other potential use-cases. For example, to pair up 'calls' with 'returns' accurately (from branch events like Intel BTS) it is necessary to identify whether the process has exec'd. Although a comm event is generated when an 'exec' happens it is also generated whenever the comm string is changed on a whim (e.g. by prctl PR_SET_NAME). This patch adds a flag to the comm event to differentiate one case from the other. In order to determine whether the kernel supports the new flag, a selection bit named 'exec' is added to struct perf_event_attr. The bit does nothing but will cause perf_event_open() to fail if the bit is set on kernels that do not have it defined. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Ingo Molnar authored
Conflicts: arch/x86/kernel/traps.c Signed-off-by: -
Peter Zijlstra authored
perf_event_comm() assumes that set_task_comm() is only called on exec(), and in particular that its only called on current. Neither are true, as Dave reported a WARN triggered by set_task_comm() being called on !current. Separate the exec() hook from the comm hook. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
- 05 Jun, 2014 16 commits
-
-
Ingo Molnar authored
Merge branch 'uprobes/core' of git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc into perf/core Pull uprobes tmpfs support patches from Oleg Nesterov. Signed-off-by:
-
Oleg Nesterov authored
Purely cosmetic, no changes in .o, 1. As Jim pointed out arch_uprobe->def looks ambiguous, rename it to ->defparam. 2. Add the comment into default_post_xol_op() to explain "regs->sp +=". 3. Remove the stale part of the comment in arch_uprobe_analyze_insn(). Suggested-by:
Jim Keniston <jkenisto@us.ibm.com> Reviewed-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Acked-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com>
-
Anshuman Khandual authored
Signed-off-by:
Anshuman Khandual <khandual@linux.vnet.ibm.com> Reviewed-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Anshuman Khandual authored
This patch adds conditional branch filtering support, enabling it for PERF_SAMPLE_BRANCH_COND in perf branch stack sampling framework by utilizing an available software filter X86_BR_JCC. Signed-off-by:
-
Anshuman Khandual authored
Adding perf record support for new branch stack filter criteria PERF_SAMPLE_BRANCH_COND. Signed-off-by:
-
Anshuman Khandual authored
This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which will extend the existing perf ABI. This will filter branches which are conditional. Various architectures can provide this functionality either with HW filtering support (if present) or with SW filtering of captured branch instructions. Signed-off-by:
-
Oleg Nesterov authored
tmpfs is widely used but as Denys reports shmem_aops doesn't have ->readpage() and thus you can't probe a binary on this filesystem. As Hugh suggested we can use shmem_read_mapping_page() in this case, just we need to check shmem_mapping() if ->readpage == NULL. Reported-by:
Denys Vlasenko <dvlasenk@redhat.com> Suggested-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
Oleg Nesterov authored
copy_insn() fails with -EIO if ->readpage == NULL, but this error is not propagated unless uprobe_register() path finds ->mm which already mmaps this file. In this case (say) "perf record" does not actually install the probe, but the user can't know about this. Move this check into uprobe_register() so that this problem can be detected earlier and reported to user. Note: this is still not perfect, - copy_insn() and arch_uprobe_analyze_insn() should be called by uprobe_register() but this is not simple, we need vm_file for read_mapping_page() (although perhaps we can pass NULL), and we need ->mm for is_64bit_mm() (although this logic is broken anyway). - uprobe_register() should be called by create_trace_uprobe(), not by probe_event_enable(), so that an error can be detected at "perf probe -x" time. This also needs more changes in the core uprobe code, uprobe register/unregister interface was poorly designed from the very beginning. Reported-by:
-
Vince Weaver authored
Make the x86 perf code use the new common PMU interrupt disabled code. Typically most x86 machines have working PMU interrupts, although some older p6-class machines had this problem. Signed-off-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
-
Vince Weaver authored
Make the ARM perf code use the new common PMU interrupt disabled code. This allows perf to work on ARM machines without a working PMU interrupt (for example, raspberry pi). Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Vince Weaver authored
Add common code to generate -ENOTSUPP at event creation time if an architecture attempts to create a sampled event and PERF_PMU_NO_INTERRUPT is set. This adds a new pmu->capabilities flag. Initially we only support PERF_PMU_NO_INTERRUPT (to indicate a PMU has no support for generating hardware interrupts) but there are other capabilities that can be added later. Signed-off-by:
-
Peter Zijlstra authored
While that mutex should guard the elements, it doesn't guard against the use-after-free that's from list_for_each_entry_rcu(). __perf_event_exit_task() can actually free the event. And because list addition/deletion is guarded by both ctx->mutex and ctx->lock, holding ctx->mutex is sufficient for reading the list, so we don't actually need the rcu list iteration. Fixes: 3a497f48 ("perf: Simplify perf_event_exit_task_context()") Reported-by:
Sasha Levin <sasha.levin@oracle.com> Tested-by:
-
Ingo Molnar authored
Conflicts: arch/x86/kernel/traps.c The kprobes enhancements are fully cooked, ship them upstream. Signed-off-by: -
Ingo Molnar authored
These bits from Oleg are fully cooked, ship them to Linus. Signed-off-by: -
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/core Pull perf/core improvements and fixes from Jiri Olsa: * Warn the user when trace command is not available (Arnaldo Carvalho de Melo) * Add warning when disabling perl scripting support due to missing devel files (Arnaldo Carvalho de Melo) * Consider header files outside perf directory in tags target (Sebastian Andrzej Siewior) * Allow overriding sysfs and proc finding with env var (Cody P Schafer) * Fix "==" into "=" in ui_browser__warning assignment (zhangdianfang) * Factor elide bool handling in sort code (Jiri Olsa) * Fix poll return value propagation (Jiri Olsa) * Fix 'make help' message error (Jianyu Zhan) Signed-off-by:
-
Ingo Molnar authored
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/urgent Pull perf/urgent fixes from Jiri Olsa: * Fix perf probe to find correct variable DIE (Masami Hiramatsu) * Fix a segfault in perf probe if asked for variable it doesn't find (Masami Hiramatsu) Signed-off-by:
-
- 04 Jun, 2014 2 commits
-
-
Masami Hiramatsu authored
Fix perf probe to find correct variable DIE which has location or external instance by tracking down the lexical blocks. Current die_find_variable() expects that the all variable DIEs which has DW_TAG_variable have a location. However, since recent dwarf information may have declaration variable DIEs at the entry of function (subprogram), die_find_variable() returns it. To solve this problem, it must track down the DIE tree to find a DIE which has an actual location or a reference for external instance. e.g. finding a DIE which origin is <0xdc73>; <1><11496>: Abbrev Number: 95 (DW_TAG_subprogram) <11497> DW_AT_abstract_origin: <0xdc42> <1149b> DW_AT_low_pc : 0x1850 [...] <2><114cc>: Abbrev Number: 119 (DW_TAG_variable) <- this is a declaration <114cd> DW_AT_abstract_origin: <0xdc73> <2><114d1>: Abbrev Number: 119 (DW_TAG_variable) [...] <3><115a7>: Abbrev Number: 105 (DW_TAG_lexical_block) <115a8> DW_AT_ranges : 0xaa0 <4><115ac>: Abbrev Number: 96 (DW_TAG_variable) <- this has a location <115ad> DW_AT_abstract_origin: <0xdc73> <115b1> DW_AT_location : 0x486c (location list) Signed-off-by:Arnaldo Carvalho de Melo <acme@kernel.org> Acked-by:
-
Masami Hiramatsu authored
Fix a segfault bug by asking for variable it doesn't find. Since the convert_variable() didn't handle error code returned from convert_variable_location(), it just passed an incomplete variable field and then a segfault was occurred when formatting the field. This fixes that bug by handling success code correctly in convert_variable(). Other callers of convert_variable_location() are correctly checking the return code. This bug was introduced by following commit. But another hidden erroneous error handling has been there previously (-ENOMEM case). commit 3d918a12Signed-off-by:
-
- 03 Jun, 2014 4 commits
-
-
Jianyu Zhan authored
Currently 'make help' message has such hint: use "make prefix=<path> <install target>" to install to a particular path like make prefix=/usr/local install install-doc But this is misleading, when I specify "prefix=/usr/local", it has got no respect at all. This is because that, "DESTDIR" is considered first. In this case, "DESTDIR" has an empty value, so "prefix" is honored. However, "prefix" is unconditionally assigned to $HOME, regardless of what it is set to from command line. So our "prefix" setting got no respect and the actual destination falls back to $HOME. This patch fixes this issue and corrects the help message. Signed-off-by:Jianyu Zhan <nasa4836@gmail.com> Acked-by:
-
Jiri Olsa authored
If the perf record command is interrupted in record__mmap_read_all function, the 'done' is set and err has the latest poll return value, which is most likely positive number (= number of pollfds ready to read). This 'positive err' is then propagated to the exit code, resulting in not finishing the perf.data header properly, causing following error in report: # perf record -F 50000 -a --- make the system real busy, so there's more chance to interrupt perf in event writing code --- ^C[ perf record: Woken up 16 times to write data ] [ perf record: Captured and wrote 30.292 MB perf.data (~1323468 samples) ] # perf report --stdio > /dev/null WARNING: The perf.data file's data size field is 0 which is unexpected. Was the 'perf record' command properly terminated? Fixing this by checking for positive poll return value and setting err to 0. Acked-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by:
-
Jiri Olsa authored
After output/sort fields refactoring, it's expensive to check the elide bool in its current location inside the 'struct sort_entry'. The perf_hpp__should_skip function gets highly noticable in workloads with high number of output/sort fields, like for: $ perf report -i perf-test.data -F overhead,sample,period,comm,pid,dso,symbol,cpu --stdio Performance report: 9.70% perf [.] perf_hpp__should_skip Moving the elide bool into the 'struct perf_hpp_fmt', which makes the perf_hpp__should_skip just single struct read. Got speedup of around 22% for my test perf.data workload. The change should not harm any other workload types. Performance counter stats for (10 runs): before: 358,319,732,626 cycles ( +- 0.55% ) 467,129,581,515 instructions # 1.30 insns per cycle ( +- 0.00% ) 150.943975206 seconds time elapsed ( +- 0.62% ) now: 278,785,972,990 cycles ( +- 0.12% ) 370,146,797,640 instructions # 1.33 insns per cycle ( +- 0.00% ) 116.416670507 seconds time elapsed ( +- 0.31% ) Acked-by: -
Jiri Olsa authored
There's no need to setup elide of sort_dso sort entry again with symbol_conf.dso_list list. The only difference were list names of memory mode data, which does not make much sense to me. Acked-by:
-
