- 29 Jan, 2016 5 commits
-
-
Wang Nan authored
There is a nasty confusion that, for kernel module, dso->kernel is not necessary to be DSO_TYPE_KERNEL or DSO_TYPE_GUEST_KERNEL. These two enums are for vmlinux. See thread [1]. We tried to fix this part but it is costy. Code machine__write_buildid_table() is another unfortunate function fall into this trap that, when issuing buildid event for a kernel module, cpumode it gives to the event is PERF_RECORD_MISC_USER, not PERF_RECORD_MISC_KERNEL. However, even with this bug, most of the time it doesn't causes real problem. I find this issue when trying to use a perf before commit 3d39ac53 ("perf machine: No need to have two DSOs lists") to parse a perf.data generated by newest perf. [1] https://lkml.org/lkml/2015/9/21/908Signed-off-by:
Wang Nan <wangnan0@huawei.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: pi3orama@163.com Link: http://lkml.kernel.org/r/1454089251-203152-1-git-send-email-wangnan0@huawei.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Mathieu Poirier authored
On some architecture the size of the private header may be dependent on the number of tracers used in the session. As such adding a "struct perf_evlist *" parameter, which should contain all the required information. Also adjusting the existing client of the interface to take the new parameter into account. Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Al Grant <al.grant@arm.com> Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: Mike Leach <mike.leach@arm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Rabin Vincent <rabin@rab.in> Cc: Tor Jeremiassen <tor@ti.com> Link: http://lkml.kernel.org/r/1452807977-8069-22-git-send-email-mathieu.poirier@linaro.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
The 'tools/perf/test/make' makefile has in its default, 'all' target builds that will pollute the source code directory, i.e. that will not use O= variable. The 'build-test' should be run as often as possible, preferrably after each non strictly non-code commit, so speed it up by selecting just the O= targets. Furthermore it tests both the Makefile.perf file, that is normally driven by the main Makefile, and the Makefile, reduce the time in half by having just MK=Makefile, the most usual, tested by 'build-test'. Please run: make -C tools/perf -f tests/make from time to time for testing also the in-place build tests. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-jrt9utscsiqkmjy3ccufostd@git.kernel.orgSigned-off-by:
-
Wang Nan authored
To prevent the feature check tests to run repeately, one time per 'tests/make' target/test, this patch utilizes the previously introduced 'feature-dump' make target and FEATURES_DUMP variable, making sure that the feature checkers run only once when doing build-test for normal test cases. However, since standard users doesn't reuse features dump result, we'd better give an option to check their behaviors. The above feature should be used to make build-test faster only. Only utilize it for build-test. Signed-off-by:
-
Wang Nan authored
'make feature-dump' should give a stable result, so even 'NO_SOMETHING=1' is given (for babeltrace, if LIBBABELTRACE=1 is not given), we should try to detect those feature and {C,LD}FLAGS. Build or not should be controled independent. Signed-off-by:
-
- 28 Jan, 2016 1 commit
-
-
Jiri Olsa authored
I see problem with test-all case speedup, because it does not comprise checks for 32bits compilations, fix it. The problem could be noticed by calling: make -C tools/perf feature-dump That would end up misdetecting the feature-compile-x32, that, building using 'gcc -mx32' needs stub headers not present in a fedora 23 devel machine and thus fail to compile, but ended up appearing as detected, i.e. present in tools/perf/FEATURE-DUMP as 'feature-compile-x32=1'. With this fix it correctly appears as 'feature-compile-x32=0' and if we uninstall the libc devel files for 32 bits (glibc-devel.i686), then the relevant variable is flipped from 'feature-compile-32=1' to 'feature-compile-32=0'. The same things happened for bionic and libbabeltrace, that were misdetected because the are no tested in test-all.c Reported-and-Tested-by:
Jiri Olsa <jolsa@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-u0sjaddf1r9m8icpd98ry7fz@git.kernel.orgSigned-off-by:
-
- 27 Jan, 2016 1 commit
-
-
Wang Nan authored
An i386 binary can be linked correctly even without correct headers. Which causes problem. For exmaple: $ mv /tmp/oxygen_root/usr/include/gnu/stubs-32.h{,.bak} $ make tools/perf Auto-detecting system features: ... dwarf: [ on ] [SNIP] GEN common-cmds.h CC perf-read-vdso32 In file included from /tmp/oxygen_root/usr/include/features.h:388:0, from /tmp/oxygen_root/usr/include/stdio.h:27, from perf-read-vdso.c:1: /tmp/oxygen_root/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include <gnu/stubs-32.h> ^ compilation terminated. ... In this patch we checks not only compiler and linker, but also basic headers in test-compile test case, make it fail on a platform lacking correct headers. Signed-off-by:
-
- 26 Jan, 2016 30 commits
-
-
Arnaldo Carvalho de Melo authored
Since it was always checking if the initialization was done, use that branch to do the initialization if not done already. With this we reduce the number of exported globals from these files. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@intel.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20160125212955.GG22501@kernel.orgSigned-off-by:
-
Namhyung Kim authored
The script and data-switch context menu are only meaningful when it deals with a data file. So add a check so that it cannot be shown when perf-top is run. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Wang Nan authored
Set FEATURE_TESTS to 'all' so all possible feature checkers are executed. Without this setting the output feature dump file miss some feature, for example, liberity. Select all checker so we won't get an incomplete feature dump file. Signed-off-by:
-
Wang Nan authored
Put feature checkers not in original FEATURE_TESTS to a new list and allow subproject select all feature checkers by setting FEATURE_TESTS to 'all'. Signed-off-by:
-
Wang Nan authored
Libbpf should check the target section before doing relocation to ensure the relocation is correct. If not, a bug in LLVM causes an error. See [1]. Also, if an incorrect BPF script uses both global variable and map, global variable whould be treated as map and be relocated without error. This patch saves the id of the map section into obj->efile and compare target section of a relocation symbol against it during relocation. Previous patch introduces a test case about this problem. After this patch: # ~/perf test BPF 37: Test BPF filter : 37.1: Test basic BPF filtering : Ok 37.2: Test BPF prologue generation : Ok 37.3: Test BPF relocation checker : Ok # perf test -v BPF ... 37.3: Test BPF relocation checker : ... libbpf: loading object '[bpf_relocation_test]' from buffer libbpf: section .strtab, size 126, link 0, flags 0, type=3 libbpf: section .text, size 0, link 0, flags 6, type=1 libbpf: section .data, size 0, link 0, flags 3, type=1 libbpf: section .bss, size 0, link 0, flags 3, type=8 libbpf: section func=sys_write, size 104, link 0, flags 6, type=1 libbpf: found program func=sys_write libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9 libbpf: section maps, size 16, link 0, flags 3, type=1 libbpf: maps in [bpf_relocation_test]: 16 bytes libbpf: section license, size 4, link 0, flags 3, type=1 libbpf: license of [bpf_relocation_test] is GPL libbpf: section version, size 4, link 0, flags 3, type=1 libbpf: kernel version of [bpf_relocation_test] is 40400 libbpf: section .symtab, size 144, link 1, flags 0, type=2 libbpf: map 0 is "my_table" libbpf: collecting relocating info for: 'func=sys_write' libbpf: Program 'func=sys_write' contains non-map related relo data pointing to section 65522 bpf: failed to load buffer Compile BPF program failed. test child finished with 0 ---- end ---- Test BPF filter subtest 2: Ok [1] https://llvm.org/bugs/show_bug.cgi?id=26243Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Tested-by:
-
Wang Nan authored
There's a bug in LLVM that it can generate unneeded relocation information. See [1] and [2]. Libbpf should check the target section of a relocation symbol. This patch adds a testcase which references a global variable (BPF doesn't support global variables). Before fixing libbpf, the new test case can be loaded into kernel, the global variable acts like the first map. It is incorrect. Result: # ~/perf test BPF 37: Test BPF filter : 37.1: Test basic BPF filtering : Ok 37.2: Test BPF prologue generation : Ok 37.3: Test BPF relocation checker : FAILED! # ~/perf test -v BPF ... libbpf: loading object '[bpf_relocation_test]' from buffer libbpf: section .strtab, size 126, link 0, flags 0, type=3 libbpf: section .text, size 0, link 0, flags 6, type=1 libbpf: section .data, size 0, link 0, flags 3, type=1 libbpf: section .bss, size 0, link 0, flags 3, type=8 libbpf: section func=sys_write, size 104, link 0, flags 6, type=1 libbpf: found program func=sys_write libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9 libbpf: section maps, size 16, link 0, flags 3, type=1 libbpf: maps in [bpf_relocation_test]: 16 bytes libbpf: section license, size 4, link 0, flags 3, type=1 libbpf: license of [bpf_relocation_test] is GPL libbpf: section version, size 4, link 0, flags 3, type=1 libbpf: kernel version of [bpf_relocation_test] is 40400 libbpf: section .symtab, size 144, link 1, flags 0, type=2 libbpf: map 0 is "my_table" libbpf: collecting relocating info for: 'func=sys_write' libbpf: relocation: insn_idx=7 Success unexpectedly: libbpf error when dealing with relocation test child finished with -1 ---- end ---- Test BPF filter subtest 2: FAILED! [1] https://llvm.org/bugs/show_bug.cgi?id=26243 [2] https://patchwork.ozlabs.org/patch/571385/Signed-off-by:
-
Arnaldo Carvalho de Melo authored
There are cases where looking at just the next and prev entries is not enough, like with: $ readelf -sW /usr/lib/debug/lib/modules/4.3.3-301.fc23.x86_64/vmlinux | grep ffffffff81065ec0 4979: ffffffff81065ec0 53 FUNC LOCAL DEFAULT 1 try_to_free_pud_page 4980: ffffffff81065ec0 53 FUNC LOCAL DEFAULT 1 try_to_free_pte_page 4981: ffffffff81065ec0 53 FUNC LOCAL DEFAULT 1 try_to_free_pmd_page So just search by name to see if the symbol is in kallsyms. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-jj1vlljg7ol4i713l60rt5ai@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
To be used in the 'vmlinux matches kallsyms' 'perf test' entry. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-m56g1853lz2c6nhnqxibq4jd@git.kernel.orgSigned-off-by:
-
Namhyung Kim authored
Now that we check more strictly what each of the menu entries need, we can stop bailing out when 'sym' is not in the --sort order, instead we let each option be added if what it needs is present. This way, for instance, we can run scripts on all samples, see DSO map details when 'dso' is in the --sort provided, etc. Signed-off-by:
-
Namhyung Kim authored
For consistency with the other sort order checks. Signed-off-by:
-
Namhyung Kim authored
We can't offer a zoom into DSO when a bucket (struct hist_entry) may have samples for more than one DSO, i.e. when 'dso' is not part of the sort order, ditto for 'Map details', fix it. Signed-off-by:
-
Namhyung Kim authored
When this feature was introduced a check was made if there was a resolved symbol under the cursor, it got lost in commit ea7cd592 ("perf hists browser: Split popup menu actions - part 2"), reinstate it. Signed-off-by:
-
Namhyung Kim authored
We can't offer a zoom into thread when a bucket (struct hist_entry) may have samples for more than one thread, i.e. when 'pid' is not part of the sort order, fix it. Signed-off-by:
-
Namhyung Kim authored
Now the UI browsers will be able to offer thread related operations only if the thread is part of the sort order in use, i.e. if hist_entry stats are all for a single thread. Signed-off-by:
-
Taeung Song authored
Explain 'hist.percentage' variable. Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/1452253193-30502-7-git-send-email-treeze.taeung@gmail.comSigned-off-by:
-
Taeung Song authored
Explain 'annotate' section and its variables. 'hide_src_code', 'use_offset', 'jump_arrows', 'show_linenr', 'show_nr_jump' and 'show_total_period'. Signed-off-by:
-
Taeung Song authored
Explain 'buildid.dir' variable. Signed-off-by:
-
Taeung Song authored
Explain 'tui' and 'gtk' sections and these variables. 'top', 'report' and 'annotate' Signed-off-by:
-
Taeung Song authored
Explain 'colors' section and its variables, used for The variables for customizing the colors used in the output for the 'report', 'top' and 'annotate' in the TUI, those are: 'top', 'medium', 'normal', 'selected', 'jump_arrows', 'addr' and 'root'. Signed-off-by:
-
Taeung Song authored
USe 'jump_arrows' config name instead of 'code' on 'colors' section. 'colors.code' config is only for jump arrows on assembly code listings i.e. │ ┌──jmp 1333 │ │ xchg %ax,%ax │ │ mov %r15,%r10 │ └─→cmp %r15,%r14 But this config name seems unfit. 'jump_arrows' is more descriptive than 'code'. Signed-off-by: -
Ben Hutchings authored
perf_event_paranoid was only documented in source code and a perf error message. Copy the documentation from the error message to Documentation/sysctl/kernel.txt. perf_cpu_time_max_percent was already documented but missing from the list at the top, so add it there. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-doc@vger.kernel.org Link: http://lkml.kernel.org/r/20160119213515.GG2637@decadent.org.uk [ Remove reference to external Documentation file, provide info inline, as before ] Signed-off-by:
-
Namhyung Kim authored
The hists__filter_by_xxx functions share same logic with different filters. Factor out the common code into the hists__filter_by_type. Signed-off-by:
Pekka Enberg <penberg@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: David Ahern <dsahern@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1453252521-24398-2-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Namhyung Kim authored
The --exclude-other option sets HIST_FILTER__PARENT bit and it's only set when a hist entry was created. DSO filters don't change this so no need to have the check in hists__filter_by_dso() IMHO. Signed-off-by:
-
Jiri Olsa authored
There's no need for the following functions to be global: perf_evsel__reset_stat_priv perf_evsel__alloc_stat_priv perf_evsel__free_stat_priv perf_evsel__alloc_prev_raw_counts perf_evsel__free_prev_raw_counts perf_evsel__alloc_stats They all ended up in util/stat.c, and they no longer need to be called from outside this object. Signed-off-by:
-
Jiri Olsa authored
With mem sampling we could get data source within mapped device file. Processing such sample would block during report phase on trying to read the device file. Chacking for device files and skip the processing if it's detected. Signed-off-by:
-
Markus Trippelsdorf authored
One line in perf_pmu__parse_unit() is indented wrongly, leading to a warning (=> error) from gcc 6: util/pmu.c:156:3: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] sret = read(fd, alias->unit, UNIT_MAX_LEN); ^~~~ util/pmu.c:153:2: note: ...this 'if' clause, but it is not if (fd == -1) ^~ Signed-off-by:Markus Trippelsdorf <markus@trippelsdorf.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 410136f5 ("tools/perf/stat: Add event unit and scale support") Link: http://lkml.kernel.org/r/20151214154440.GC1409@x4Signed-off-by:
-
Jiri Olsa authored
Mel reported stddev reporting was broken due to following commit: 106a94a0 ("perf stat: Introduce read_counters function") This commit merged interval and overall counters reading into single read_counters function. The old interval code cleaned the stddev data for some reason (it's never displayed in interval mode) and the mentioned commit kept on cleaning the stddev data in merged function, which resulted in the stddev not being displayed. Removing the wrong stddev data cleanup init_stats call. Reported-and-Tested-by:
Mel Gorman <mgorman@techsingularity.net> Signed-off-by:
-
Jiri Olsa authored
Set correct width for unresolved mem_dcacheline addr. Signed-off-by:
-
Markus Trippelsdorf authored
The issue was pointed out by gcc-6's -Wmisleading-indentation. Signed-off-by:
-
Markus Trippelsdorf authored
The while loop was spinning. Fix by removing a semicolon. The issue was pointed out by gcc-6's -Wmisleading-indentation. Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Acked-by:
-
- 21 Jan, 2016 3 commits
-
-
Alexander Shishkin authored
We are currently using asynchronous deallocation in the error path in AUX mmap code, which is unnecessary and also presents a problem for users that wish to probe for the biggest possible buffer size they can get: they'll get -EINVAL on all subsequent attemts to allocate a smaller buffer before the asynchronous deallocation callback frees up the pages from the previous unsuccessful attempt. Currently, gdb does that for allocating AUX buffers for Intel PT traces. More specifically, overwrite mode of AUX pmus that don't support hardware sg (some implementations of Intel PT, for instance) is limited to only one contiguous high order allocation for its buffer and there is no way of knowing its size without trying. This patch changes error path freeing to be synchronous as there won't be any contenders for the AUX pages at that point. Reported-by:
Markus Metzger <markus.t.metzger@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: vince@deater.net Link: http://lkml.kernel.org/r/1453216469-9509-1-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by:
-
Stephane Eranian authored
This patch enables the uncore_imc PMU for Intel SkyLake Desktop processors (Core i7-6700, model 94). It is possible to compute memory read/write bandwidth using: $ perf stat -a -e uncore_imc/data_reads/,uncore_imc/data_writes/ .... Signed-off-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Peter Zijlstra authored
There is a race against perf_event_exit_task() vs event_function_call(),find_get_context(),perf_install_in_context() (iow, everyone). Since there is no permanent marker on a context that its dead, it is quite possible that we access (and even modify) a context after its passed through perf_event_exit_task(). For instance, find_get_context() might find the context still installed, but by the time we get to perf_install_in_context() it might already have passed through perf_event_exit_task() and be considered dead, we will however still add the event to it. Solve this by marking a ctx dead by setting its ctx->task value to -1, it must be !0 so we still know its a (former) task context. Signed-off-by:
-
