- 23 May, 2018 11 commits
-
-
Adrian Hunter authored
x86 PTI entry trampolines all map to the same physical page. If that is reflected in the program headers of /proc/kcore, then do the same for the copy of kcore. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/1526986485-6562-18-git-send-email-adrian.hunter@intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Adrian Hunter authored
Identify and copy any sections for x86 PTI entry trampolines. Signed-off-by:
-
Adrian Hunter authored
In preparation to add more program headers, get rid of kernel_map and modules_map by moving ->kernel_map and ->modules_map to newly allocated entries in the ->phdrs list. Signed-off-by:
-
Adrian Hunter authored
In preparation to add more program headers, iterate phdrs instead of assuming there is only one for the kernel text and one for the modules. Signed-off-by:
-
Adrian Hunter authored
In preparation to add more program headers, layout the relative offset of each section. Signed-off-by:
-
Adrian Hunter authored
In preparation to add more program headers, calculate offset from the number of phdrs. Signed-off-by:
-
Adrian Hunter authored
In preparation to add more program headers, keep a count of phdrs. Signed-off-by:
-
Adrian Hunter authored
Currently, kcore_copy makes 2 program headers, one for the kernel text (namely kernel_map) and one for the modules (namely modules_map). Now more program headers are needed, but treating each program header as a special case results in much more code. Instead, in preparation to add more program headers, change to keep program header data (phdr_data) in a list. Signed-off-by:
-
Jin Yao authored
When we enable the group, for tui/stdio2, the output first line includes the group event string. While for stdio, it will show only one event. For example, perf record -e cycles,branches ./div perf annotate --group --stdio Percent | Source code & Disassembly of div for cycles (44407 samples) ...... The first line doesn't include the event 'branches'. With this patch, it will show the correct group even string. perf annotate --group --stdio Percent | Source code & Disassembly of div for cycles, branches (44407 samples) ...... Signed-off-by:Jin Yao <yao.jin@linux.intel.com> Suggested-by:
-
Adrian Hunter authored
Like the kernel text, the location of x86 PTI entry trampolines must be recorded in the perf.data file. Like the kernel, synthesize a mmap event for that, and add processing for it. Signed-off-by:
-
Adrian Hunter authored
Create maps for x86 PTI entry trampolines, based on symbols found in kallsyms. It is also necessary to keep track of whether the trampolines have been mapped particularly when the kernel dso is kcore. Signed-off-by:
-
- 22 May, 2018 4 commits
-
-
Adrian Hunter authored
Identify extra kernel maps by name so that they can be distinguished from the kernel map and module maps. Signed-off-by:
-
Adrian Hunter authored
When kernel symbols are derived from /proc/kallsyms only (not using vmlinux or /proc/kcore) map_groups__split_kallsyms() is used. However that function makes assumptions that are not true with entry trampoline symbols. For now, remove the entry trampoline symbols at that point, as they are no longer needed at that point. Signed-off-by:
-
Adrian Hunter authored
On x86_64 the PTI entry trampolines are not in the kernel map created by perf tools. That results in the addresses having no symbols and prevents annotation. It also causes Intel PT to have decoding errors at the trampoline addresses. Workaround that by creating maps for the trampolines. At present the kernel does not export information revealing where the trampolines are. Until that happens, the addresses are hardcoded. Signed-off-by:
-
Adrian Hunter authored
Add a function to return the number of the machine's available CPUs. Signed-off-by:
-
- 21 May, 2018 3 commits
-
-
Jin Yao authored
With the '--group' option, even for non-explicit group, 'perf annotate' will enable the group output. For example, $ perf record -e cycles,branches ./div $ perf annotate main --stdio --group : Disassembly of section .text: : : 00000000004004b0 <main>: : main(): : : return i; : } : : int main(void) : { 0.00 0.00 : 4004b0: push %rbx : int i; : int flag; : volatile double x = 1212121212, y = 121212; : : s_randseed = time(0); 0.00 0.00 : 4004b1: xor %edi,%edi : srand(s_randseed); 0.00 0.00 : 4004b3: mov $0x77359400,%ebx : : return i; : } : But if without --group, there is only one event reported. $ perf annotate main --stdio : Disassembly of section .text: : : 00000000004004b0 <main>: : main(): : : return i; : } : : int main(void) : { 0.00 : 4004b0: push %rbx : int i; : int flag; : volatile double x = 1212121212, y = 121212; : : s_randseed = time(0); 0.00 : 4004b1: xor %edi,%edi : srand(s_randseed); 0.00 : 4004b3: mov $0x77359400,%ebx : : return i; : } Signed-off-by: -
Jin Yao authored
Since we created a new function perf_evlist__force_leader(), remove the old code and use that new evlist method. Signed-off-by:
-
Jin Yao authored
For non-explicit group (e.g. those created with -e '{eventA,eventB}'), 'perf report' supports a option '--group' which can enable group output. We also need to support 'perf annotate' with the same '--group'. Create a new function perf_evlist__force_leader() which contains common code to force setting the group leader. Signed-off-by:
-
- 19 May, 2018 5 commits
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-4.18-20180519' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Record min/max LBR cycles (>= Skylake) and add 'perf annotate' TUI hotkey to show it (c) (Jin Yao) - Fix machine->kernel_start for PTI on x86 (Adrian Hunter) - Make machine->env->arch always available, e.g. in 'perf top', not just when reading that info from perf.data files (Adrian Hunter) - Reduce the number of files read at 'perf' start, leaving information such as cacheline size, tracefs mount point determination, max_stack, etc, to be lazily read as tools needs then (Arnaldo Carvalho de Melo) - Fix up BPF include and examples install messages (Arnaldo Carvalho de Melo) - Fix up callchain addresses and symbol offsets in 'perf script', to help correlating with objdump output (Sandipan Das) Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Adrian Hunter authored
Opickn x86_64, PTI entry trampolines are less than the start of kernel text, but still above 2^63. So leave kernel_start = 1ULL << 63 for x86_64. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/1526548928-20790-7-git-send-email-adrian.hunter@intel.comSigned-off-by:
-
Adrian Hunter authored
Add a function to identify the machine architecture. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Before: INSTALL lib install include/bpf/*.h '/home/acme/lib/include/perf/bpf' INSTALL lib install examples/bpf/*.c '/home/acme/lib/examples/perf/bpf' After: INSTALL lib INSTALL include/bpf INSTALL lib INSTALL examples/bpf Reported-by:
-
Jin Yao authored
In the 'perf annotate' view, a new hotkey 'c' is created for showing the min/max cycles. For example, when press 'c', the annotate view is: Percent│ IPC Cycle(min/max) │ │ │ Disassembly of section .text: │ │ 000000000003aab0 <random@@GLIBC_2.2.5>: 8.22 │3.92 sub $0x18,%rsp │3.92 mov $0x1,%esi │3.92 xor %eax,%eax │3.92 cmpl $0x0,argp_program_version_hook@@G │3.92 1(2/1) ↓ je 20 │ lock cmpxchg %esi,__abort_msg@@GLIBC_P │ ↓ jne 29 │ ↓ jmp 43 │1.10 20: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+ 8.93 │1.10 1(5/1) ↓ je 43 When press 'c' again, the annotate view is switched back: Percent│ IPC Cycle │ │ │ Disassembly of section .text: │ │ 000000000003aab0 <random@@GLIBC_2.2.5>: 8.22 │3.92 sub $0x18,%rsp │3.92 mov $0x1,%esi │3.92 xor %eax,%eax │3.92 cmpl $0x0,argp_program_version_hook@@GLIBC_2.2.5+0x │3.92 1 ↓ je 20 │ lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0 │ ↓ jne 29 │ ↓ jmp 43 │1.10 20: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0 8.93 │1.10 1 ↓ je 43 Signed-off-by:
-
- 18 May, 2018 2 commits
-
-
Jin Yao authored
Currently perf has a feature to account cycles for LBRs For example, on skylake: perf record -b ... perf report or perf annotate And then browsing the annotate browser gives average cycle counts for program blocks. For some analysis it would be useful if we could know not only the average cycles but also the min and max cycles. This patch records the min and max cycles. Signed-off-by:
-
Sandipan Das authored
Since the ip shown for a symbol is now always a virtual address, it becomes difficult to correlate this with objdump output and determine the exact instruction address. So, we always show the offset from the start of the symbol. This can be verified on a powerpc64le system running Fedora 27 as follows: # perf probe -a sys_write # perf record -e probe:sys_write -g ~/test Before applying this patch: # perf script test 9710 [013] 95614.332431: probe:sys_write: (c0000000004025b0) c0000000004025b0 sys_write (/lib/modules/4.17.0-rc4+/build/vmlinux) c00000000000b9e0 system_call (/lib/modules/4.17.0-rc4+/build/vmlinux) 7fffb70d8234 __GI___libc_write (/usr/lib64/libc-2.26.so) 7fffb7052c74 _IO_file_write@@GLIBC_2.17 (/usr/lib64/libc-2.26.so) 5afc1818 [unknown] ([unknown]) 7fffb7051a60 new_do_write (/usr/lib64/libc-2.26.so) 7fffb7054638 _IO_do_write@@GLIBC_2.17 (/usr/lib64/libc-2.26.so) 7fffb7054bbc _IO_file_overflow@@GLIBC_2.17 (/usr/lib64/libc-2.26.so) 7fffb7055a24 __overflow (/usr/lib64/libc-2.26.so) 7fffb7044548 _IO_puts (/usr/lib64/libc-2.26.so) 10000440 main (/home/sandipan/test) 7fffb6fe36a0 generic_start_main.isra.0 (/usr/lib64/libc-2.26.so) 7fffb6fe3898 __libc_start_main (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) ... After applying this patch: # perf script test 9710 [013] 95614.332431: probe:sys_write: (c0000000004025b0) c0000000004025b0 sys_write+0x10 (/lib/modules/4.17.0-rc4+/build/vmlinux) c00000000000b9e0 system_call+0x58 (/lib/modules/4.17.0-rc4+/build/vmlinux) 7fffb70d8234 __GI___libc_write+0x24 (/usr/lib64/libc-2.26.so) 7fffb7052c74 _IO_file_write@@GLIBC_2.17+0x44 (/usr/lib64/libc-2.26.so) 5afc1818 [unknown] ([unknown]) 7fffb7051a60 new_do_write+0x90 (/usr/lib64/libc-2.26.so) 7fffb7054638 _IO_do_write@@GLIBC_2.17+0x38 (/usr/lib64/libc-2.26.so) 7fffb7054bbc _IO_file_overflow@@GLIBC_2.17+0x14c (/usr/lib64/libc-2.26.so) 7fffb7055a24 __overflow+0x64 (/usr/lib64/libc-2.26.so) 7fffb7044548 _IO_puts+0x218 (/usr/lib64/libc-2.26.so) 10000440 main+0x20 (/home/sandipan/test) 7fffb6fe36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so) 7fffb6fe3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) ... Signed-off-by:Sandipan Das <sandipan@linux.vnet.ibm.com> Tested-by:
-
- 17 May, 2018 9 commits
-
-
Sandipan Das authored
When perf data is recorded with the call-graph option enabled, the callchain shown by perf script shows the binary offsets of the symbols as the ip. This is incorrect for kernel symbols as the ip values are always off by a fixed offset depending on the architecture. If the offsets from the start of the symbols are printed, they are also incorrect for both kernel and userspace symbols. Without the call-graph option, the callchain shows the virtual addresses of the symbols rather than their binary offsets. The offsets printed in this case are also correct. This fixes the inconsistency in perf script's output. This can be verified on a powerpc64le system running Fedora 27 as follows: # cat /proc/kallsyms | grep sys_write ... c0000000004025a0 T sys_write c0000000004025a0 T __se_sys_write ... # perf probe -a sys_write Before applying this patch: # perf record -e probe:sys_write -g ~/test # perf script -F ip,sym,symoff 4125b0 sys_write+0x8000000000008010 1b9e0 system_call+0x8000000000008058 118234 __GI___libc_write+0xffff0000f52c0024 92c74 _IO_file_write@@GLIBC_2.17+0xffff0000f52c0044 5afbfd8a [unknown] 91a60 new_do_write+0xffff0000f52c0090 94638 _IO_do_write@@GLIBC_2.17+0xffff0000f52c0038 94bbc _IO_file_overflow@@GLIBC_2.17+0xffff0000f52c014c 95a24 __overflow+0xffff0000f52c0064 84548 _IO_puts+0xffff0000f52c0218 440 main+0xffffffffe0000020 236a0 generic_start_main.isra.0+0xffff0000f52c0140 23898 __libc_start_main+0xffff0000f52c00b8 0 [unknown] ... # perf record -e probe:sys_write ~/test # perf script -F ip,sym,symoff c0000000004025b0 sys_write+0x10 ... After applying this patch: # perf record -e probe:sys_write -g ~/test # perf script -F ip,sym,symoff c0000000004025b0 sys_write+0x10 c00000000000b9e0 system_call+0x58 7fffb70d8234 __GI___libc_write+0x24 7fffb7052c74 _IO_file_write@@GLIBC_2.17+0x44 5afc1818 [unknown] 7fffb7051a60 new_do_write+0x90 7fffb7054638 _IO_do_write@@GLIBC_2.17+0x38 7fffb7054bbc _IO_file_overflow@@GLIBC_2.17+0x14c 7fffb7055a24 __overflow+0x64 7fffb7044548 _IO_puts+0x218 10000440 main+0x20 7fffb6fe36a0 generic_start_main.isra.0+0x140 7fffb6fe3898 __libc_start_main+0xb8 0 [unknown] ... # perf record -e probe:sys_write ~/test # perf script -F ip,sym,symoff c0000000004025b0 sys_write+0x10 ... Signed-off-by: -
Arnaldo Carvalho de Melo authored
Let tools that need to have those variables with the sysctl current values use a function that will read them. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-1ljj3oeo5kpt2n1icfd9vowe@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
It is not read as commonly as 'page_size', so it makes sense to read it lazily, caching its value when it is first read. Less files open unconditionally at startup. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-35xhrq91u94uc1djtclek1ie@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Adopt it from the kernel sources, will be used soon. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-oubheiqj8edo5rzewt11cbn0@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Not anymore accessed outside this library, keep it private. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-wg1m07flfrg1rm06jjzie8si@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
That takes care of using the right call to get the tracing_path directory, the one that will end up calling tracing_path_set() to figure out where tracefs is mounted. One more step in doing just lazy reading of system structures to reduce the number of operations done unconditionaly at 'perf' start. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-42zzi0f274909bg9mxzl81bu@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Instead of accessing the trace_events_path variable directly, that may not have been properly initialized wrt detecting where tracefs is mounted. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-id7hzn1ydgkxbumeve5wapqz@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
When using for_each_event() we needlessly rebuild the whole path to the tracepoint directory, reuse the dir_path instead, saving some cycles and reducing the size of the next patch. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-54bcs15n0cp6gwcgpc4hptyc@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
To make reading events files a tad more compact than with get_tracing_files("events/foo"). Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-do6xgtwpmfl8zjs1euxsd2du@git.kernel.orgSigned-off-by:
-
- 16 May, 2018 6 commits
-
-
Arnaldo Carvalho de Melo authored
One should use tracing_path_mount() instead, so more things get done lazily instead of at every 'perf' tool call startup. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-fci4yll35idd9yuslp67vqc2@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Its only used in the file it is defined, so just make it static. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-p5x29u6mq2ml3mtnbg9844ad@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
We check what perf_config__init() does at each perf_config() call, namely if the static perf_config instance was created, so instead of bailing out in that case, try to allocate it, bailing if it fails. Now to get the perf_config() call out of the start of perf's main() function, doing it also lazily. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Taeung Song <treeze.taeung@gmail.com> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-4bo45k6ivsmbxpfpdte4orsg@git.kernel.orgSigned-off-by:
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-4.18-20180516' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Add '-e intel_pt//u' test to the 'parse-events' 'perf test' entry, to help avoiding regressions in the events parser such as one that caused a revert in v4.17-rc (Arnaldo Carvalho de Melo) - Fix NULL return handling in bpf__prepare_load() (YueHaibing) - Warn about 'perf buildid-cache --purge-all' failures (Ravi Bangoria) - Add infrastructure to help in writing eBPF C programs to be used with '-e name.c' type events in tools such as 'record' and 'trace', with headers for common constructs and an examples directory that will get populated as we add more such helpers and the 'perf bpf' branch that Jiri Olsa has been working on (Arnaldo Carvalho de Melo) - Handle uncore event aliases in small groups properly (Kan Liang) - Use the "_stest" symbol to identify the kernel map when loading kcore (Adrian Hunter) Signed-off-by:
-
YueHaibing authored
bpf_object__open()/bpf_object__open_buffer can return error pointer or NULL, check the return values with IS_ERR_OR_NULL() in bpf__prepare_load and bpf__prepare_load_buffer Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: netdev@vger.kernel.org Link: https://lkml.kernel.org/n/tip-psf4xwc09n62al2cb9s33v9h@git.kernel.orgSigned-off-by:
-
Kan Liang authored
Perf stat doesn't count the uncore event aliases from the same uncore block in a group, for example: perf stat -e '{unc_m_cas_count.all,unc_m_clockticks}' -a -I 1000 # time counts unit events 1.000447342 <not counted> unc_m_cas_count.all 1.000447342 <not counted> unc_m_clockticks 2.000740654 <not counted> unc_m_cas_count.all 2.000740654 <not counted> unc_m_clockticks The output is very misleading. It gives a wrong impression that the uncore event doesn't work. An uncore block could be composed by several PMUs. An uncore event alias is a joint name which means the same event runs on all PMUs of a block. Perf doesn't support mixed events from different PMUs in the same group. It is wrong to put uncore event aliases in a big group. The right way is to split the big group into multiple small groups which only include the events from the same PMU. Only uncore event aliases from the same uncore block should be specially handled here. It doesn't make sense to mix the uncore events with other uncore events from different blocks or even core events in a group. With the patch: # time counts unit events 1.001557653 140,833 unc_m_cas_count.all 1.001557653 1,330,231,332 unc_m_clockticks 2.002709483 85,007 unc_m_cas_count.all 2.002709483 1,429,494,563 unc_m_clockticks Reported-by:Andi Kleen <ak@linux.intel.com> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Acked-by:
-
