- 12 Jun, 2014 16 commits
-
-
Jiri Olsa authored
Testing that perf properly closes opened dso objects and tries to reopen in case we run out of allowed file descriptors for dso data. Acked-by:
Namhyung Kim <namhyung@kernel.org> 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> Reviewed by: David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/1401892622-30848-14-git-send-email-jolsa@kernel.orgSigned-off-by:
Jiri Olsa <jolsa@kernel.org>
-
Jiri Olsa authored
Adding test that setup test_dso_data__fd_limit and test dso data file descriptors are cached appropriately. Acked-by:
-
Jiri Olsa authored
Making the test_file function to be reusable for new tests coming in following patches. Also changing the template name of temp files to "/tmp/perf-test-XXXXXX" to easily identify & blame. Acked-by:
-
Jiri Olsa authored
In upcoming tests we will setup process limits, which might affect other tests. Spawning child for each test to prevent this. Acked-by:
David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/1401892622-30848-11-git-send-email-jolsa@kernel.orgSigned-off-by:
-
Jiri Olsa authored
Adding descriptions/explanations for dso__data_* interface functions. Acked-by:
-
Jiri Olsa authored
Adding do_open function that tries to close opened dso objects in case we fail to open the dso due to to crossing the allowed RLIMIT_NOFILE limit. Acked-by:
-
Jiri Olsa authored
Adding file size check, because the lseek will succeed for any offset behind file size and thus succeed when it was expected to fail. Factoring the code to check the offset against file size earlier in the flow. Acked-by:
-
Jiri Olsa authored
Caching dso data file descriptors to avoid expensive re-opens especially during DWARF unwind. We keep dsos data file descriptors open until their count reaches the half of the current fd open limit (RLIMIT_NOFILE). In this case we close file descriptor of the first opened dso object. We've got overall speedup (~27% for my workload) of report: 'perf report --stdio -i perf-test.data' (3 runs) (perf-test.data size was around 12GB) current code: 545,640,944,228 cycles ( +- 0.53% ) 785,255,798,320 instructions ( +- 0.03% ) 366.340910010 seconds time elapsed ( +- 3.65% ) after change: 435,895,036,114 cycles ( +- 0.26% ) 636,790,271,176 instructions ( +- 0.04% ) 266.481463387 seconds time elapsed ( +- 0.13% ) Acked-by: -
Jiri Olsa authored
Adding global count of opened dso objects so we could properly limit the number of opened dso data file descriptors. Acked-by:
-
Jiri Olsa authored
Adding global list of opened dso objects, so we can track them and use the list for caching dso data file descriptors. Acked-by:
-
Jiri Olsa authored
Adding data_fd into dso object so we could handle caching of opened dso file data descriptors coming int next patches. Adding dso__data_close interface to keep the data_fd updated when the descriptor is closed. Acked-by:
-
Jiri Olsa authored
Add separated structure/namespace for data related variables. We are going to add mode of them, so this way they will be clearly separated. Acked-by:
-
Jiri Olsa authored
Caching registers value into an array. Got about 4% speed up of perf_reg_value function for report command processing dwarf unwind stacks. Output from report over 1.5 GB data with DWARF unwind stacks: (TODO fix perf diff) current code: 5.84% perf perf [.] perf_reg_value change: 1.94% perf perf [.] perf_reg_value And little bit of overall speed up: (perf stat -r 5 -e '{cycles,instructions}:u' ...) current code: 310,298,611,754 cycles ( +- 0.33% ) 439,669,689,341 instructions ( +- 0.03% ) 188.656753166 seconds time elapsed ( +- 0.82% ) change: 291,315,329,878 cycles ( +- 0.22% ) 391,763,485,304 instructions ( +- 0.03% ) 180.742249687 seconds time elapsed ( +- 0.64% ) Acked-by: -
Namhyung Kim authored
When configuring event perf checked a wrong condition that user specified both of freq (-F) and period (-c) or the event has no default value. This worked because most of events don't have default value and only tracepoint events have default of 1 (and it's not desirable to change it for those events). However, Andi's downloadable event patch changes the situation so it cannot change the value for those events. Fix it by allowing override the default value if user gives one of the options. $ perf record -a -e uops_retired.all -F 4000 sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.325 MB perf.data (~14185 samples) ] $ perf evlist -F cpu/uops_retired.all/: sample_freq=4000 Signed-off-by:
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements from Arnaldo Carvalho de Melo: User visible: * Improve 'perf probe' error messages, moving some diagnostic messages to only appear in --verbose mode and fixing up some error reporting related to variables and struct members. (Masami Hiramatsu) * Reflow 'perf timechart' man page. (Stanislav Fomichev) Developer stuff: * Be more precise when reporting missing libraries in a static tool build. (Arnaldo Carvalho de Melo) * Show error messages from the multiple make invoked from 'make build-test'. (Arnaldo Carvalho de Melo) Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
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:
-
- 10 Jun, 2014 2 commits
-
-
Stanislav Fomichev authored
Move options away from examples. Signed-off-by:
Stanislav Fomichev <stfomichev@yandex-team.ru> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Ramkumar Ramachandra <artagnon@gmail.com> Link: http://lkml.kernel.org/r/20140610095216.GO26511@stfomichev-desktop.yandex.netSigned-off-by:
-
Masami Hiramatsu authored
Improve error messages of 'perf probe --line' mode. Currently 'perf probe' shows the "Debuginfo analysis failed" message with an error code when the given symbol is not found: ----- # perf probe -L page_cgroup_init_flatmem Debuginfo analysis failed. (-2) Error: Failed to show lines. ----- But -2 (-ENOENT) means that the given source line or function was not found. With this patch, 'perf probe' shows the correct error message: ----- # perf probe -L page_cgroup_init_flatmem Specified source line is not found. Error: Failed to show lines. ----- There is also another debug error code is shown in the same function after get_real_path(). This removes that too. Signed-off-by:Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@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/20140606071406.6788.47850.stgit@kbuild-fedora.novalocalSigned-off-by:
-
- 09 Jun, 2014 15 commits
-
-
Masami Hiramatsu authored
Fix an error message when failed to find given address in --vars mode. Without this fix, perf probe -V doesn't show the final "Error" message if it fails to find given source line. Moreover, it tells it fails to find "variables" instead of the source line. ----- # perf probe -V foo@bar Failed to find variables at foo@bar (0) ----- The result also shows mysterious error code. Actually the error returns 0 or -ENOENT means that it just fails to find the address of given source line. (0 means there is no matching address, and -ENOENT means there is an entry(DIE) but it has no instance, e.g. an empty inlined function) This fixes it to show what happened and the final error message as below. ----- # perf probe -V foo@bar Failed to find the address of foo@bar Error: Failed to show vars. ----- Signed-off-by: -
Masami Hiramatsu authored
Show error code and description only in verbose mode if 'perf probe' command failed. Current 'perf probe' shows error code with final error message, and that is meaningless for many users. This changes error messages to show the error code and its description only in verbose mode (-v option). Without this patch: ----- # perf probe -a do_execve@hoge Probe point 'do_execve@hoge' not found. Error: Failed to add events. (-2) ----- With this patch, normally the message doesn't show the misterious error number: ----- # perf probe -a do_execve@hoge Probe point 'do_execve@hoge' not found. Error: Failed to add events. ----- And in verbose mode, it also shows additional error messages as below: ----- # perf probe -va do_execve@hoge probe-definition(0): do_execve@hoge symbol:do_execve file:hoge line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (6 entries long) Using /lib/modules/3.15.0-rc8+/build/vmlinux for symbols Open Debuginfo file: /lib/modules/3.15.0-rc8+/build/vmlinux Try to find probe point from debuginfo. Probe point 'do_execve@hoge' not found. Error: Failed to add events. Reason: No such file or directory (Code: -2) ----- Reported-by:Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by:
-
Masami Hiramatsu authored
Improve the error message if we can not find given member in the given structure. Currently perf probe shows a wrong error message as below. ----- # perf probe getname_flags:65 "result->BOGUS" result(type:filename) has no member BOGUS. Failed to find 'result' in this function. Error: Failed to add events. (-22) ----- The first message is correct, but the second one is not, since we didn't fail to find a variable but fails to find the member of given variable. ----- # perf probe getname_flags:65 "result->BOGUS" result(type:filename) has no member BOGUS. Error: Failed to add events. (-22) ----- With this patch, the error message shows only the first one. And if we really failed to find given variable, it tells us so. ----- # perf probe getname_flags:65 "BOGUS" Failed to find 'BOGUS' in this function. Error: Failed to add events. (-2) ----- Reported-by: -
Arnaldo Carvalho de Melo authored
Before: [acme@zoo linux]$ make -C tools/perf -f tests/make make_static make: Entering directory `/home/git/linux/tools/perf' - make_static: cd . && make -f Makefile DESTDIR=/tmp/tmp.JcWuM4Zu9f LDFLAGS=-static make: *** [make_static] Error 1 make: Leaving directory `/home/git/linux/tools/perf' [acme@zoo linux]$ After: [acme@zoo linux]$ make -C tools/perf -f tests/make make_static make: Entering directory `/home/git/linux/tools/perf' - make_static: cd . && make -f Makefile DESTDIR=/tmp/tmp.X3su83i14u LDFLAGS=-static cd . && make -f Makefile DESTDIR=/tmp/tmp.X3su83i14u LDFLAGS=-static BUILD: Doing 'make -j4' parallel build config/Makefile:303: *** No static glibc found, please install glibc-static. Stop. make[1]: *** [all] Error 2 test: test -x ./perf make: Leaving directory `/home/git/linux/tools/perf' [acme@zoo linux]$ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> 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-h4kby5wyp6nfev3882rzm3r9@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
When the user does: make -C tools/perf LDFLAGS=-static asking for a static build, and the glibc-static (or equivalent) is not found, the message wasn't clear, stating that one of glibc-devel or glibc-static wasn't installed, clarify it checking if -static is present in LDFLAGS. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> 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-7e0sfobbzgeydzi9gsz8ss3m@git.kernel.orgSigned-off-by:
-
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: -
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:
-
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:
-
