On Tue, 22 Oct 2024 11:21:34 +0200 Jean-Michel Hautbois <jeanmichel.hautbois@xxxxxxxxxx> wrote:
I was not really expecting you to review the m68k one no :-). I think I have other issues which might have impact on ftrace too. For instance, when I launch cyclictest I have a warning about HRTIMERS: # cyclictest -p 99 WARN: stat /dev/cpu_dma_latency failed: No such file or directory WARN: High resolution timers not available policy: fifo: loadavg: 1.21 0.40 0.14 1/122 245 T: 0 ( 245) P:99 I:1000 C: 11203 Min: 92 Act: 623 Avg: 775 Max: 3516 The latencies are quite high...
Yes, if you don't have high resolution timers, the latency will be high.
But regarding ftrace it seems that the trace is not able to give me more than a microsecond precision. I addded a few trace_printk() in a driver of mine and I get: irq/182-dspi-sl-112 [000] D.... 277.160000: dspi_interrupt: Received 2 bytes irq/182-dspi-sl-112 [000] D.... 277.160000: dspi_interrupt: Received 2 bytes irq/182-dspi-sl-112 [000] D.... 277.163000: dspi_interrupt: dspi_interrupt irq/182-dspi-sl-112 [000] D.... 277.163000: dspi_interrupt: TX FIFO overflow irq/182-dspi-sl-112 [000] D.... 277.163000: dspi_interrupt: Restart FIFO Do you have any clue ?
Yes. The ring buffer clock is dependent on the architecture's clock. By default, it uses whatever the scheduler clock uses. If the scheduler clock is 1ms resolution, so will the tracing data be. -- Steve
