- 14 Apr, 2014 3 commits
-
-
Namhyung Kim authored
The patch 3a3ffa2e ("tools lib traceevent: Report better error message on bad function args") added the error message but it seems there's no reason to call warning() directly. So change it to do_warning_event() to provide event information too. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1395192174-26273-2-git-send-email-namhyung@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@redhat.com>
-
Namhyung Kim authored
It's sometimes useful to know where the parse failure was occurred. Add do_warning_event() macro to see the failing event. It now shows the messages like below: $ perf test 5 5: parse events tests : Warning: [kvmmmu:kvm_mmu_get_page] bad op token { Warning: [kvmmmu:kvm_mmu_sync_page] bad op token { Warning: [kvmmmu:kvm_mmu_unsync_page] bad op token { Warning: [kvmmmu:kvm_mmu_prepare_zap_page] bad op token { Warning: [kvmmmu:fast_page_fault] function is_writable_pte not defined Warning: [xen:xen_mmu_ptep_modify_prot_commit] function sizeof not defined Warning: [xen:xen_mmu_ptep_modify_prot_start] function sizeof not defined Warning: [xen:xen_mmu_set_pgd] function sizeof not defined Warning: [xen:xen_mmu_set_pud] function sizeof not defined Warning: [xen:xen_mmu_set_pmd] function sizeof not defined ... Signed-off-by: -
Namhyung Kim authored
On perf top, the -s option is used for --sort, but the man page contains invalid documentation of -s option for --sym-annotate. Signed-off-by:
-
- 19 Mar, 2014 1 commit
-
-
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 and fixes from Arnaldo: User visible: * Fixup header alignment in 'perf sched latency' output (Ramkumar Ramachandra) * Fix off-by-one error in 'perf timechart record' argv handling (Ramkumar Ramachandra) * Print the evsel name in the annotate stdio output, prep to fix support outputting annotation for multiple events, not just for the first one (Arnaldo Carvalho de Melo) Internals: * Use tid in mmap/mmap2 events to find maps (Don Zickus) * Record the reason for filtering an address_location (Namhyung Kim) * Apply all filters to an addr_location (Namhyung Kim) * Merge al->filtered with hist_entry->filtered in report/hists (Namhyung Kim) * Fix memory leak when synthesizing thread records (Namhyung Kim) * Use ui__has_annotation() in 'report' (Namhyung Kim) Cleanups: * Remove unused thread__find_map function (Jiri Olsa) * Remove unused simple_strtoul() function (Ramkumar Ramachandra) Documentation: * Update function names in debug messages (Ramkumar Ramachandra) * Update some code references in design.txt (Ramkumar Ramachandra) Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 18 Mar, 2014 14 commits
-
-
Ramkumar Ramachandra authored
Moreover, the corresponding function in include/linux/kernel.h is marked obsolete. Signed-off-by:
Ramkumar Ramachandra <artagnon@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/1395176715-4465-1-git-send-email-artagnon@gmail.comSigned-off-by:
-
Ramkumar Ramachandra authored
Update the names of some functions and enums in design.txt. The document still has some stale information, but the motivation behind this patch is to allow a developer to quickly grep and learn about the associated structures. Signed-off-by:
-
Ramkumar Ramachandra authored
perf_event_open() was renamed to sys_perf_event_open(); update the debug messages to reflect this. Signed-off-by:
-
Jiri Olsa authored
Because it's not used any more. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
So that when showing multiple events annotations, we can figure out which is which: # perf record -a -e instructions,cycles sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.826 MB perf.data (~36078 samples) ] # perf evlist instructions cycles # perf annotate intel_idle 2> /dev/null | head -1 Percent | Source code & Disassembly of vmlinux for instructions # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> 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-n1r51l329434js84qtb2c6l9@git.kernel.orgSigned-off-by:
-
Namhyung Kim authored
Since we introduced the ui__has_annotation() for that, don't open code it. Signed-off-by:
-
Namhyung Kim authored
Checking default guest machine should be done before allocating event structures otherwise it'll leak memory. Signed-off-by:
-
Don Zickus authored
Now that we can properly synthesize threads system-wide, make sure the mmap and mmap2 events use tids instead of pids to locate their maps. Signed-off-by:
Don Zickus <dzickus@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1393429527-167840-3-git-send-email-dzickus@redhat.comSigned-off-by:
-
Namhyung Kim authored
I.e. don't drop al->filtered entries, create the hist_entries and use its ->filtered bitmap, that is kept with the same semantics for its bitmap, leaving the filtering to be done at the hist_entry level, i.e. in the UIs. This will allow zooming in/out the filters. Signed-off-by:
Namhyung Kim <namhyung.kim@lge.com> Acked-by:
-
Namhyung Kim authored
Instead of bailing out as soon as we find a filter that applies, go on checking all of them so that we can zoom in/out filters. We also need to make sure we only update al->filtered after thread__find_addr_map(), because there is where al->filtered gets initialized to zero. This will increase the cost of processing when all we don't need this toggling, but will provide flexibility for the TUI and GTK+ interfaces, that will incur in creating the hist_entries just once. Signed-off-by:
-
Namhyung Kim authored
By turning the addr_location->filtered member from a boolean to a u8 bitmap, reusing (and extending) the hist_filter enum for that. This patch doesn't change the logic at all, as it keeps the meaning of al->filtered !0 to mean that the entry _was_ filtered, so no change in how this value is interpreted needs to be done at this point. This will be soon used in upcoming patches. Signed-off-by:
-
Ramkumar Ramachandra authored
Before: --------------------------------------------------------------------------------------------------------------- Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at | --------------------------------------------------------------------------------------------------------------- ... | | | | | git:24540 | 336.622 ms | 10 | avg: 0.032 ms | max: 0.062 ms | max at: 115610.111046 s git:24541 | 0.457 ms | 1 | avg: 0.000 ms | max: 0.000 ms | max at: 0.000000 s ----------------------------------------------------------------------------------------- TOTAL: | 396.542 ms | 353 | --------------------------------------------------- After: ----------------------------------------------------------------------------------------------------------------- Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at | ----------------------------------------------------------------------------------------------------------------- ... | | | | | git:24540 | 336.622 ms | 10 | avg: 0.032 ms | max: 0.062 ms | max at: 115610.111046 s git:24541 | 0.457 ms | 1 | avg: 0.000 ms | max: 0.000 ms | max at: 0.000000 s ----------------------------------------------------------------------------------------------------------------- TOTAL: | 396.542 ms | 353 | --------------------------------------------------- Signed-off-by:
-
Ramkumar Ramachandra authored
Since 367b3152 (perf timechart: Add support for -P and -T in timechart recording, 2013-11-01), the 'perf timechart record' command stopped working: $ perf timechart record -- git status Workload failed: No such file or directory This happens because of an off-by-one error while preparing the argv for cmd_record(): it attempts to execute the command 'status' and complains that it doesn't exist. Fix this error. Signed-off-by:
Stanislav Fomichev <stfomichev@yandex-team.ru> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stanislav Fomichev <stfomichev@yandex-team.ru> Link: http://lkml.kernel.org/r/1394985965-2332-1-git-send-email-artagnon@gmail.comSigned-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 and fixes from Arnaldo: User visible: * Add several futex 'perf bench' microbenchmarks (Davidlohr Bueso) * Speed up thread map generation (Don Zickus) * Fix synthesizing mmaps for threads (Don Zickus) * Fix invalid output on event group stdio report (Namhyung Kim) * Introduce 'perf kvm --list-cmds' command line option for use by scripts (Ramkumar Ramachandra) Documentation: * Clarify load-latency information in the 'perf mem' docs (Andi Kleen) * Clarify x86 register naming in 'perf probe' docs (Andi Kleen) Refactorings: * hists browser refactorings to reuse code accross UIs (Namhyung Kim) Signed-off-by:
-
- 14 Mar, 2014 17 commits
-
-
Jiri Olsa authored
Forcing the code to always search thread by pid/tid pair. The PID value will be needed in future to determine the process thread leader for map groups sharing. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.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: 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/1394805606-25883-3-git-send-email-jolsa@redhat.comSigned-off-by:
-
Don Zickus authored
When trying to capture perf data on a system running spejbb2013, perf hung for about 15 minutes. This is because it took that long to gather about 10,000 thread maps and process them. I don't think a user wants to wait that long. Instead, recognize that thread maps are roughly equivalent to pid maps and just quickly copy those instead. To do this, I synthesize 'fork' events, this eventually calls thread__fork() and copies the maps over. The overhead goes from 15 minutes down to about a few seconds. -- V2: based on Jiri's comments, moved malloc up a level and made sure the memory was freed Signed-off-by: -
Ramkumar Ramachandra authored
Introduce $ perf kvm --list-cmds to dump a raw list of commands for use by the completion script. In order to do this, introduce parse_options_subcommand() for handling subcommands as a special case in the parse-options machinery. Signed-off-by:
David Ahern <dsahern@gmail.com> Acked-by:
-
Namhyung Kim authored
Those functions need evsel to investigate event group and it's passed via hpp->ptr. However as it can be missed easily so it's better to pass it via an argument IMHO. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Its one level up thread__find_addr_location, where it will look in different domains for a sample: user, kernel, hypervisor, etc. Will soon be used by a patchkit by Andi Kleen. Cc: Adrian Hunter <adrian.hunter@intel.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: 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-so6nxkh7xj48bc5kq4jpj991@git.kernel.orgSigned-off-by:
-
Don Zickus authored
When printing the raw dump of a data file, the header.misc is printed as a decimal. Unfortunately, that field is a bit mask, so it is hard to interpret as a decimal. Print in hex, so the user can easily see what bits are set and more importantly what type of info it is conveying. V2: add 0x in front per Jiri Olsa Signed-off-by:
-
Namhyung Kim authored
The __hpp__color_fmt used in the TUI code can be replace by the generic code with small change in print_fn callback. And it also needs to move callback function to the generic __hpp__fmt(). No functional changes intended. Signed-off-by:
-
Namhyung Kim authored
Instead of the pointer to buffer and its size so that it can also get private argument passed along with hpp. This is a preparation of further change. Signed-off-by:
-
Namhyung Kim authored
The __hpp__color_fmt used in the gtk code can be replace by the generic code with small change in print_fn callback. This is a preparation to upcoming changes and no functional changes intended. Signed-off-by:
Pekka Enberg <penberg@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Pekka Enberg <penberg@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1393809254-4480-3-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Namhyung Kim authored
When some of group member has 0 overhead, it printed previous percentage instead of 0.00%. It's because passing integer 0 as a percent rather than double 0.0 so the remaining bits came from garbage. The TUI and GTK don't have this problem since they pass 0.0. Before: # Samples: 845 of event 'anon group { cycles, cache-references, cache-misses }' # Event count (approx.): 174775051 # # Overhead Samples # ........................ .................................... # 20.32% 8.58% 73.51% 45 30 138 6.87% 6.87% 6.87% 21 0 0 5.29% 0.31% 0.31% 10 1 0 1.89% 1.89% 1.89% 6 0 0 1.76% 1.76% 1.76% 2 0 0 After: # Overhead Samples # ........................ .................................... # 20.32% 8.58% 73.51% 45 30 138 6.87% 0.00% 0.00% 21 0 0 5.29% 0.31% 0.00% 10 1 0 1.89% 0.00% 0.00% 6 0 0 1.76% 0.00% 0.00% 2 0 0 Signed-off-by: -
Don Zickus authored
Currently if a process creates a bunch of threads using pthread_create and then perf is run in system_wide mode, the mmaps for those threads are not captured with a synthesized mmap event. The reason is those threads are not visible when walking the /proc/ directory looking for /proc/<pid>/maps files. Instead they are discovered using the /proc/<pid>/tasks file (which the synthesized comm event uses). This causes problems when a program is trying to map a data address to a tid. Because the tid has no maps, the event is dropped. Changing the program to look up using the pid instead of the tid, finds the correct maps but creates ugly hacks in the program to carry the correct tid around. Fix this by moving the walking of the /proc/<pid>/tasks up a level (out of the comm function) based on Arnaldo's suggestion. Tweaked things a bit to special case the 'full' bit and 'guest' check. Signed-off-by:
-
Andi Kleen authored
Clarify how to specify x86 registers in perf probe. I recently ran into this problem and had to figure it out from the source. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Link: http://lkml.kernel.org/r/1393596135-4227-3-git-send-email-andi@firstfloor.orgSigned-off-by:
-
Andi Kleen authored
Clarify in the documentation that 'perf mem report' reports use-latency, not load/store-latency on Intel systems. This often causes confusion with users. Signed-off-by:
-
Davidlohr Bueso authored
Block a bunch of threads on a futex and requeue them on another, N at a time. This program is particularly useful to measure the latency of nthread requeues without waking up any tasks -- thus mimicking a regular futex_wait. An example run: $ perf bench futex requeue -r 100 -t 64 Run summary [PID 151011]: Requeuing 64 threads (from 0x7d15c4 to 0x7d15c8), 1 at a time. [Run 1]: Requeued 64 of 64 threads in 0.0400 ms [Run 2]: Requeued 64 of 64 threads in 0.0390 ms [Run 3]: Requeued 64 of 64 threads in 0.0400 ms ... [Run 100]: Requeued 64 of 64 threads in 0.0390 ms Requeued 64 of 64 threads in 0.0399 ms (+-0.37%) Signed-off-by:
Davidlohr Bueso <davidlohr@hp.com> Acked-by:
Darren Hart <dvhart@linux.intel.com> Cc: Aswin Chandramouleeswaran <aswin@hp.com> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Low <jason.low2@hp.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Scott J Norton <scott.norton@hp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Waiman Long <Waiman.Long@hp.com> Link: http://lkml.kernel.org/r/1387081917-9102-4-git-send-email-davidlohr@hp.comSigned-off-by:
-
Davidlohr Bueso authored
Block a bunch of threads on a futex and wake them up, N at a time. This program is particularly useful to measure the latency of nthread wakeups in non-error situations: all waiters are queued and all wake calls wakeup one or more tasks. An example run: $ perf bench futex wake -t 512 -r 100 Run summary [PID 27823]: blocking on 512 threads (at futex 0x7e10d4), waking up 1 at a time. [Run 1]: Wokeup 512 of 512 threads in 6.0080 ms [Run 2]: Wokeup 512 of 512 threads in 5.2280 ms [Run 3]: Wokeup 512 of 512 threads in 4.8300 ms ... [Run 100]: Wokeup 512 of 512 threads in 5.0100 ms Wokeup 512 of 512 threads in 5.0109 ms (+-2.25%) Signed-off-by:
-
Davidlohr Bueso authored
Introduce futexes to perf-bench and add a program that stresses and measures the kernel's implementation of the hash table. This is a multi-threaded program that simply measures the amount of failed futex wait calls - we only want to deal with the hashing overhead, so a negative return of futex_wait_setup() is enough to do the trick. An example run: $ perf bench futex hash -t 32 Run summary [PID 10989]: 32 threads, each operating on 1024 [private] futexes for 10 secs. [thread 0] futexes: 0x19d9b10 ... 0x19dab0c [ 418713 ops/sec ] [thread 1] futexes: 0x19daca0 ... 0x19dbc9c [ 469913 ops/sec ] [thread 2] futexes: 0x19dbe30 ... 0x19dce2c [ 479744 ops/sec ] ... [thread 31] futexes: 0x19fbb80 ... 0x19fcb7c [ 464179 ops/sec ] Averaged 454310 operations/sec (+- 0.84%), total secs = 10 Signed-off-by:
-
Stephane Eranian authored
This patch fixes a bug with the SNB/IVB/HSW uncore mmeory controller support. The PCI Ids tables for the memory controller were missing end markers. That could cause random crashes on boot during or after PCI device registration. Signed-off-by:
Stephane Erainan <eranian@google.com> Cc: peterz@infradead.org Cc: zheng.z.yan@intel.com Cc: bp@alien8.de Cc: ak@linux.intel.com Link: http://lkml.kernel.org/r/20140313120436.GA14236@quadSigned-off-by:
-
- 12 Mar, 2014 1 commit
-
-
Stephane Eranian authored
This patch fixes a compilation problem (unused variable) with the new SNB/IVB/HSW uncore IMC code. [ In -v2 we simplify the fix as suggested by Peter Zjilstra. ] Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140311235329.GA28624@quadSigned-off-by:
-
- 11 Mar, 2014 4 commits
-
-
Jiri Olsa authored
User space callchains and user space stack dump were disabled for function trace event. Mailing list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2 Catching up with perf and disabling user space callchains and DWARF unwind (uses user stack dump) for function trace event. Adding following warnings when callchains are used for function trace event: # perf record -g -e ftrace:function ... Disabling user space callchains for function trace event. ... # ./perf record --call-graph=dwarf -e ftrace:function ... Cannot use DWARF unwind for function trace event, falling back to framepointers. Disabling user space callchains for function trace event. ... Signed-off-by:
-
Jiri Olsa authored
Recent issues with user space callchains processing within page fault handler tracing showed as Peter said 'there's just too much fail surface'. The user space stack dump is just another source of the this issue. Related list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2Suggested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Jiri Olsa authored
Recent issues with user space callchains processing within page fault handler tracing showed as Peter said 'there's just too much fail surface'. Related list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2Suggested-by:
-
Dongsheng Yang authored
Commit: 411cf180 perf/x86/uncore: fix initialization of cpumask introduced the function uncore_cpumask_init(), which is only called in __init intel_uncore_init(). But it is not marked with __init, which produces the following warning: WARNING: vmlinux.o(.text+0x2464a): Section mismatch in reference from the function uncore_cpumask_init() to the function .init.text:uncore_cpu_setup() The function uncore_cpumask_init() references the function __init uncore_cpu_setup(). This is often because uncore_cpumask_init lacks a __init annotation or the annotation of uncore_cpu_setup is wrong. This patch marks uncore_cpumask_init() with __init. Signed-off-by:
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Acked-by:
-
