[v4,0/2] Add basic tracing support for m68k

Message

Jean-Michel Hautbois Dec. 4, 2024, 7:14 a.m. UTC

In order to debug latency issues, I wanted to use ftrace on my M54418
coldfire. Sadly, it is not supported yet.
Thanks to Steven [1] it does not sound too difficult.

This small series adds basic functions to make it work, and for the few
tests I could do, it seems to be working well.

Here is a simple output I get:

```

            bash-232     [000] d..3.   947.629000: thread_noise:     bash:232 start 947.629000000 duration 0 ns
      timerlat/0-274     [000] .....   947.629000: #51598 context thread timer_latency    409280 ns
            bash-232     [000] d.h..   947.630000: #51599 context    irq timer_latency    110720 ns
            bash-232     [000] dnh1.   947.630000: irq_noise: timer:206 start 947.629000000 duration 1000000 ns
            bash-232     [000] d..3.   947.630000: thread_noise:     bash:232 start 947.630000000 duration 0 ns
      timerlat/0-274     [000] .....   947.630000: #51599 context thread timer_latency    407168 ns
            bash-232     [000] d.h..   947.631000: #51600 context    irq timer_latency    108608 ns
            bash-232     [000] dnh1.   947.631000: irq_noise: timer:206 start 947.630000000 duration 1000000 ns
            bash-232     [000] d..3.   947.631000: thread_noise:     bash:232 start 947.631000000 duration 0 ns
      timerlat/0-274     [000] .....   947.631000: #51600 context thread timer_latency    401472 ns
```

I used this on my board and afaik, it works quite well.

```

 telnetd-229       0Dnh4.   13us+:      229:120:R   + [000]     118: 49:R irq/100-enet-fe
 telnetd-229       0Dnh4.   53us+: <stack trace>
 => __trace_stack
 => probe_wakeup
 => try_to_wake_up
 => wake_up_process
 => __handle_irq_event_percpu
 => handle_irq_event
 => handle_level_irq
 => generic_handle_irq
 => do_IRQ
 => inthandler
 => ip_finish_output2
 => __ip_finish_output
 => ip_output
 => __ip_queue_xmit
 => ip_queue_xmit
 => __tcp_transmit_skb
 => tcp_write_xmit
 => __tcp_push_pending_frames
 => tcp_push
 => tcp_sendmsg_locked
 => tcp_sendmsg
 => inet_sendmsg
 => sock_write_iter
 => vfs_write
 => ksys_write
 => sys_write
 => system_call
 telnetd-229       0Dnh4.   68us!: wake_up_process <-__handle_irq_event_percpu
 telnetd-229       0D..3.  348us+: __schedule <-preempt_schedule_irq
 telnetd-229       0D..3.  368us+:      229:120:R ==> [000]     118: 49:R irq/100-enet-fe
 telnetd-229       0D..3.  395us : <stack trace>
 => __trace_stack
 => probe_wakeup_sched_switch
 => __schedule
 => preempt_schedule_irq
 => Lkernel_return
 => ip_finish_output2
 => __ip_finish_output
 => ip_output
 => __ip_queue_xmit
 => ip_queue_xmit
 => __tcp_transmit_skb
 => tcp_write_xmit
 => __tcp_push_pending_frames
 => tcp_push
 => tcp_sendmsg_locked
 => tcp_sendmsg
 => inet_sendmsg
 => sock_write_iter
 => vfs_write
 => ksys_write
 => sys_write
 => system_call
```

[1]: https://lore.kernel.org/linux-m68k/[e-mail]

Signed-off-by: Jean-Michel Hautbois <[e-mail]>
---
Changes in v4:
- Take Steve's v1 remarks !
- Link to v3: https://lore.kernel.org/r/[e-mail]

Changes in v3:
- Do not unconditionaly select the frame pointers
- Link to v2: https://lore.kernel.org/r/[e-mail]

Changes in v2:
- Use the frame pointer and declare it
- Comments on trace_irq have been tested, but adding the trace_on/off in
  entry.S fails badly
- Link to v1: https://lore.kernel.org/r/[e-mail]

---
Jean-Michel Hautbois (2):
      m68k: Enable traceirqs
      arch: m68k: Add STACKTRACE support

 arch/m68k/Kconfig             |  6 ++++
 arch/m68k/kernel/Makefile     |  1 +
 arch/m68k/kernel/stacktrace.c | 70 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 77 insertions(+)
---
base-commit: e70140ba0d2b1a30467d4af6bcfe761327b9ec95
change-id: 20241021-add-m68k-tracing-support-36c18d2233d8

Best regards,