Skip to main content

Browse the archive

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 
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
 
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
2 parent s ff5f168 + 52d7523
Raw File
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
back to top