0

Best case would be, if I had a (debug)-tool which runs in the background and tells me the name of the process or driver that breaks my latency requirement to my system. Which tool is suitable? Do you have a short example of its usage for the following case?

Test case:

  • The oscilloscope measures the time between the trigger of a GPIO input and the response on a GPIO output. Usually the response time is 150µs. I trigger every 25ms.
  • My linux user test program uses poll() and read()+write() to mirror the detected signal of the input as response back to an output.
  • The Linux kernel is patched with the Preempt_rt patch.
  • In the dimension of hours I can see response time peaks of up to 20ms.
falkb
  • 1,294
  • 11
  • 35
  • Thanks for the question-close requests but it is a programmer issue of debugging, and who else than programmers can answer me? – falkb Feb 27 '19 at 13:54
  • Software recommendation questions are **off-topic** on Stack Overflow, even if they are *programming* questions. But in SE network there is a [site](https://softwarerecs.stackexchange.com/) exactly for such kind of questions. – Tsyvarev Feb 27 '19 at 14:01

1 Answers1

0

The best real chance is to

  1. switch on tracing in the kernel configuration and build such Linux kernel:
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_DEBUG_FS=y
  1. then run your application until weird things happen by using a tool trace-cmd
trace-cmd start -b 10000 -e 'sched_wakeup*' -e sched_switch -e gpio_value -e irq_handler_entry -e irq_handler_exit /tmp/myUserApplication

and get a trace.dat file.

trace-cmd stop
trace-cmd extract
  1. Load that trace.dat file in KernelShark and analyse the CPUs, threads, interrupts, kworker threads and user space threads. It's great to see which blocks the system.
falkb
  • 1,294
  • 11
  • 35