Hi John again, Hi list :)
On 12/20/2024 3:05 PM, John Ogness wrote:
There are various kernel configurations that affect latency. But I am
curious... Why do you think a maximum latency of 80us on an $80 board is
large? What maximum latencies are you expecting? And why do you think it
is not "under control"?
I played around some more and coincidentally found a way to trigger even
longer latencies:
stress -m 4 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 4
This gives me latencies in excess of 500 us. I even saw 800 us once or
so in my tests.. The traces still look fine. Here's one for 438us:
rtla timerlat hit stop tracing
## CPU 3 hit stop tracing, analyzing it ##
IRQ handler delay: 0.00 us
(0.00 %)
IRQ latency: 439.58 us
Blocking thread:
stress:1706
Blocking thread stack trace
-> timerlat_irq
-> __hrtimer_run_queues
-> hrtimer_interrupt
-> arch_timer_handler_phys
-> handle_percpu_devid_irq
-> generic_handle_domain_irq
-> gic_handle_irq
-> call_on_irq_stack
-> do_interrupt_handler
-> el0_interrupt
-> __el0_irq_handler_common
-> el0t_64_irq_handler
-> el0t_64_irq
------------------------------------------------------------------------
IRQ latency: 439.58 us (100%)
A Raspberry Pi 4 seems to be less susceptible to this stress test. There
the maximum latencies go to ca. 200 us. I will try a couple of kernels
including the one in the OSADL farm.
Kind regards,
FPS
--
https://blog.dfdx.eu
