talos-obmc-linux/tools/perf, branch dev-4.13

perf pmu: Unbreak perf record for arm/arm64 with events with explicit PMU

2017-10-21T15:55:06+00:00

commit 66ec11919a0f96e936bb731fdbc2851316077d26 upstream. Currently, perf record is broken on arm/arm64 systems when the PMU is specified explicitly as part of the event, e.g. $ ./perf record -e armv8_cortex_a53/cpu_cycles/u true In such cases, perf record fails to open events unless perf_event_paranoid is set to -1, even if the PMU in question supports mode exclusion. Further, even when perf_event_paranoid is toggled, no samples are recorded. This is an unintended side effect of commit: e3ba76deef23064f ("perf tools: Force uncore events to system wide monitoring) ... which assumes that if a PMU has an associated cpu_map, it is an uncore PMU, and forces events for such PMUs to be system-wide. This is not true for arm/arm64 systems, which can have heterogeneous CPUs. To account for this, multiple CPU PMUs are exposed, each with a "cpus" field under sysfs, which the perf tool parses into a cpu_map. ARM PMUs do not have a "cpumask" file, and only have a "cpus" file. For the gory details as to why, see commit: 7e3fcffe95544010 ("perf pmu: Support alternative sysfs cpumask") Given all of this, we can instead identify uncore PMUs by explicitly checking for a "cpumask" file, and restore arm/arm64 PMU support back to a working state. This patch does so, adding a new perf_pmu::is_uncore field, and splitting the existing cpumask parsing so that it can be reused. Signed-off-by: Mark Rutland Tested-by Will Deacon Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: e3ba76deef23064f ("perf tools: Force uncore events to system wide monitoring) Link: http://lkml.kernel.org/r/1507315102-5942-1-git-send-email-mark.rutland@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf script: Add missing separator for "-F ip,brstack" (and brstackoff)

2017-10-18T07:38:31+00:00

commit e9516c0813aeb89ebd19ec0ed39fbfcd78b6ef3a upstream. Prior to commit 55b9b50811ca ("perf script: Support -F brstack,dso and brstacksym,dso"), we were printing a space before the brstack data. It seems that this space was important. Without it, parsing is difficult. Very sorry for the mistake. Notice here how the "ip" and "brstack" run together: $ perf script -F ip,brstack | head -n 1 22e18c40x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 After this diff, sanity is restored: $ perf script -F ip,brstack | head -n 1 22e18c4 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 0x22e195d/0x22e1990/P/-/-/0 0x22e18e9/0x22e1943/P/-/-/0 0x22e1a69/0x22e18c0/P/-/-/0 0x22e19f7/0x22e1a20/P/-/-/0 0x22e1910/0x22e19ee/P/-/-/0 0x22e19e2/0x22e190b/P/-/-/0 0x22e19a1/0x22e19d0/P/-/-/0 Signed-off-by: Mark Santaniello Cc: Alexander Shishkin Cc: Peter Zijlstra Fixes: 55b9b50811ca ("perf script: Support -F brstack,dso and brstacksym,dso") Link: http://lkml.kernel.org/r/20171006080722.3442046-1-marksan@fb.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2017-07-21T18:12:48+00:00

Pull perf fixes from Ingo Molnar: "Two hw-enablement patches, two race fixes, three fixes for regressions of semantics, plus a number of tooling fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Add proper condition to run sched_task callbacks perf/core: Fix locking for children siblings group read perf/core: Fix scheduling regression of pinned groups perf/x86/intel: Fix debug_store reset field for freq events perf/x86/intel: Add Goldmont Plus CPU PMU support perf/x86/intel: Enable C-state residency events for Apollo Lake perf symbols: Accept zero as the kernel base address Revert "perf/core: Drop kernel samples even though :u is specified" perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target perf evsel: State in the default event name if attr.exclude_kernel is set perf evsel: Fix attr.exclude_kernel setting for default cycles:p

mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

2017-07-12T23:26:03+00:00

__GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to the page allocator. This has been true but only for allocations requests larger than PAGE_ALLOC_COSTLY_ORDER. It has been always ignored for smaller sizes. This is a bit unfortunate because there is no way to express the same semantic for those requests and they are considered too important to fail so they might end up looping in the page allocator for ever, similarly to GFP_NOFAIL requests. Now that the whole tree has been cleaned up and accidental or misled usage of __GFP_REPEAT flag has been removed for !costly requests we can give the original flag a better name and more importantly a more useful semantic. Let's rename it to __GFP_RETRY_MAYFAIL which tells the user that the allocator would try really hard but there is no promise of a success. This will work independent of the order and overrides the default allocator behavior. Page allocator users have several levels of guarantee vs. cost options (take GFP_KERNEL as an example) - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_ attempt to free memory at all. The most light weight mode which even doesn't kick the background reclaim. Should be used carefully because it might deplete the memory and the next user might hit the more aggressive reclaim - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic allocation without any attempt to free memory from the current context but can wake kswapd to reclaim memory if the zone is below the low watermark. Can be used from either atomic contexts or when the request is a performance optimization and there is another fallback for a slow path. - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) - non sleeping allocation with an expensive fallback so it can access some portion of memory reserves. Usually used from interrupt/bh context with an expensive slow path fallback. - GFP_KERNEL - both background and direct reclaim are allowed and the _default_ page allocator behavior is used. That means that !costly allocation requests are basically nofail but there is no guarantee of that behavior so failures have to be checked properly by callers (e.g. OOM killer victim is allowed to fail currently). - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior and all allocation requests fail early rather than cause disruptive reclaim (one round of reclaim in this implementation). The OOM killer is not invoked. - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator behavior and all allocation requests try really hard. The request will fail if the reclaim cannot make any progress. The OOM killer won't be triggered. - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior and all allocation requests will loop endlessly until they succeed. This might be really dangerous especially for larger orders. Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL because they already had their semantic. No new users are added. __alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if there is no progress and we have already passed the OOM point. This means that all the reclaim opportunities have been exhausted except the most disruptive one (the OOM killer) and a user defined fallback behavior is more sensible than keep retrying in the page allocator. [akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c] [mhocko@suse.com: semantic fix] Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz [mhocko@kernel.org: address other thing spotted by Vlastimil] Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.org Signed-off-by: Michal Hocko Acked-by: Vlastimil Babka Cc: Alex Belits Cc: Chris Wilson Cc: Christoph Hellwig Cc: Darrick J. Wong Cc: David Daney Cc: Johannes Weiner Cc: Mel Gorman Cc: NeilBrown Cc: Ralf Baechle Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

perf symbols: Accept zero as the kernel base address

2017-07-12T14:47:05+00:00

Which is the case in S/390, where symbols were not being resolved because machine__get_kernel_start was only setting machine->kernel_start when the just successfully loaded kernel symtab had its map->start set to !0, when it was left at (1ULL << 63) assuming a partitioning of the address space for user/kernel, which is not the case in S/390 nor in Sparc. So just check if map__load() was successfull and set machine->kernel_start to zero, fixing kernel symbol resolution on S/390. Test performed by Thomas: ---- I like this patch. I have done a new build and removed all my debug output to start from scratch. Without your patch I get this: # Samples: 4 of event 'cpu-clock' # Event count (approx.): 1000000 # # Children Self Command Shared Object Symbol # ........ ........ ....... ................ ........................ 75.00% 0.00% true [unknown] [k] 0x00000000004bedda | ---0x4bedda | |--50.00%--0x42693a | | | --25.00%--0x2a72e0 | 0x2af0ca | 0x3d1003fe4c0 | --25.00%--0x4272bc 0x26fa84 and with your patch (I just rebuilt the perf tool, nothing else and used the same perf.data file as input): # Samples: 4 of event 'cpu-clock' # Event count (approx.): 1000000 # # Children Self Command Shared Object Symbol # ........ ........ ....... .......................... .................................. 75.00% 0.00% true [kernel.vmlinux] [k] pgm_check_handler | ---pgm_check_handler do_dat_exception handle_mm_fault __handle_mm_fault filemap_map_pages | |--25.00%--rcu_read_lock_held | rcu_lockdep_current_cpu_online | 0x3d1003ff4c0 | --25.00%--lock_release Looks good to me.... ---- Reported-and-Tested-by: Thomas-Mich Richter Cc: Adrian Hunter Cc: David Ahern Cc: Hendrik Brueckner Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Cc: Zvonko Kosic Link: http://lkml.kernel.org/n/tip-dk0n1uzmbe0tbthrpfqlx6bz@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target

2017-07-10T19:36:40+00:00

When the jump instruction is displayed at the row 0 in annotate view, the arrow is broken. An example: 16.86 │ ┌──je 82 0.01 │ movsd (%rsp),%xmm0 │ movsd 0x8(%rsp),%xmm4 │ movsd 0x8(%rsp),%xmm1 │ movsd (%rsp),%xmm3 │ divsd %xmm4,%xmm0 │ divsd %xmm3,%xmm1 │ movsd (%rsp),%xmm2 │ addsd %xmm1,%xmm0 │ addsd %xmm2,%xmm0 │ movsd %xmm0,(%rsp) │82: sub $0x1,%ebx 83.03 │ ↑ jne 38 │ add $0x10,%rsp │ xor %eax,%eax │ pop %rbx │ ← retq The patch increments the row number before checking with 0. Signed-off-by: Yao Jin Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 944e1abed9e1 ("perf ui browser: Add method to draw up/down arrow line") Link: http://lkml.kernel.org/r/1496901704-30275-1-git-send-email-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: State in the default event name if attr.exclude_kernel is set

2017-07-10T19:19:25+00:00

When no event is specified perf will use the "cycles" hardware event with the highest precision available in the processor, and excluding kernel events for non-root users, so make that clear in the event name by setting the "u" event modifier, i.e. "cycles:upp". E.g.: The default for root: # perf record usleep 1 # perf evlist -v cycles:ppp: ..., precise_ip: 3, exclude_kernel: 0, ... # And for !root: $ perf record usleep 1 $ perf evlist -v cycles:uppp: ... , precise_ip: 3, exclude_kernel: 1, ... $ Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-lf29zcdl422i9knrgde0uwy3@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf evsel: Fix attr.exclude_kernel setting for default cycles:p

2017-07-10T19:14:48+00:00

To allow probing the max attr.precise_ip setting for non-root users we unconditionally set attr.exclude_kernel, which makes the detection work but should be done only for !root, fix it. Cc: Adrian Hunter Cc: Andy Lutomirski Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Fixes: 97365e81366f ("perf evsel: Set attr.exclude_kernel when probing max attr.precise_ip") Link: http://lkml.kernel.org/n/tip-bl6bbxzxloonzvm4nvt7oqgj@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

Merge tag 'perf-urgent-for-mingo-4.12-20170704' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

2017-07-05T07:10:37+00:00

Pull perf/urgent fixes from Arnaldo Carvalho de Melo: User visible changes: - Fix max attr.precise_ip probing to make perf use the best cycles:p available in the processor for non root users (Arnaldo Carvalho de Melo) - Fix processing of MMAP events for 32-bit binaries on 64-bit systems when unwind support is not fully integrated, fixing DSO and symbol resolution (Jiri Olsa) Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ingo Molnar

perf unwind: Do not fail due to missing unwind support

2017-07-04T14:43:58+00:00

We currently fail the MMAP event processing if we don't have the MMAP event's specific arch unwind support compiled in. That's wrong and can lead to unresolved mmaps in report output for 32bit binaries on 64bit server, like in this example on x86_64 server: $ cat ex.c int main(int argc, char **argv) { while (1) {} } $ gcc -o ex -m32 ex.c $ perf record ./ex ^C[ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.371 MB perf.data (9322 samples) ] Before: $ perf report --stdio SNIP # Overhead Command Shared Object Symbol # ........ ....... ................ ...................... # 100.00% ex [unknown] [.] 0x00000000080483de 0.00% ex [unknown] [.] 0x00000000f76dba4f 0.00% ex [unknown] [.] 0x00000000f76e4c11 0.00% ex [unknown] [.] 0x00000000f76daa30 After: $ perf report --stdio SNIP # Overhead Command Shared Object Symbol # ........ ....... ............. ............... # 100.00% ex ex [.] main 0.00% ex ld-2.24.so [.] _dl_start 0.00% ex ld-2.24.so [.] do_lookup_x 0.00% ex ld-2.24.so [.] _start The fix is not to fail, just warn if there's not unwind support compiled in. Reported-by: Michael Lyle Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: He Kuang Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20170704131131.27508-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo