Revision 23300f657594656e7ebac3130b43460ebc4381cc authored by Linus Torvalds on 19 February 2016, 16:40:05 UTC, committed by Linus Torvalds on 19 February 2016, 16:40:05 UTC
Pull arm64 fixes from Will Deacon: "Here are some more arm64 fixes for 4.5. This has mostly come from Yang Shi, who saw some issues under -rt that also affect mainline. The rest of it is pretty small, but still worth having. We've got an old issue outstanding with valid_user_regs which will likely wait until 4.6 (since it would really benefit from some time in -next) and another issue with kasan and idle which should be fixed next week. Apart from that, pretty quiet here (and still no sign of the THP issue reported on s390...) Summary: - Allow EFI stub to use strnlen(), which is required by recent libfdt - Avoid smp_processor_id() in preempt context during unwinding - Avoid false Kasan warnings during unwinding - Ensure early devices are picked up by the IOMMU DMA ops - Avoid rebuilding the kernel for the 'install' target - Run fixup handlers for alignment faults on userspace access" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: mm: allow the kernel to handle alignment faults on user accesses arm64: kbuild: make "make install" not depend on vmlinux arm64: dma-mapping: fix handling of devices registered before arch_initcall arm64/efi: Make strnlen() available to the EFI namespace arm/arm64: crypto: assure that ECB modes don't require an IV arm64: make irq_stack_ptr more robust arm64: debug: re-enable irqs before sending breakpoint SIGTRAP arm64: disable kasan when accessing frame->fp in unwind_frame
events-nmi.txt
NMI Trace Events
These events normally show up here:
/sys/kernel/debug/tracing/events/nmi
--
nmi_handler:
You might want to use this tracepoint if you suspect that your
NMI handlers are hogging large amounts of CPU time. The kernel
will warn if it sees long-running handlers:
INFO: NMI handler took too long to run: 9.207 msecs
and this tracepoint will allow you to drill down and get some
more details.
Let's say you suspect that perf_event_nmi_handler() is causing
you some problems and you only want to trace that handler
specifically. You need to find its address:
$ grep perf_event_nmi_handler /proc/kallsyms
ffffffff81625600 t perf_event_nmi_handler
Let's also say you are only interested in when that function is
really hogging a lot of CPU time, like a millisecond at a time.
Note that the kernel's output is in milliseconds, but the input
to the filter is in nanoseconds! You can filter on 'delta_ns':
cd /sys/kernel/debug/tracing/events/nmi/nmi_handler
echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter
echo 1 > enable
Your output would then look like:
$ cat /sys/kernel/debug/tracing/trace_pipe
<idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1
<idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1
<idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1
<idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...