On 12-04-22 04:56 PM, Andy Walls wrote: > > If, in your system, IRQ service for device A under some circumstances > has precendence over IRQ service for the CX23418 and hence holds off its > service; and the irq handler in the driver for device A decides to > perform some some long I/O operations with device A; then it doesn't > matter how fast your CPU is. Yes, quite true. I was forgetting about how nasty an irq handler can be on other hardware. > You may wish to use perf or ftrace, or some other tool/method of > measuring kernel interrupt handling latency to find out what causes any > delays from the CX23418 raising its IRQ line to cx18_irq_handler() being > called by the kernel. Excellent idea. I'm afraid I'm quite (read: very) green in the area of kernel performance profiling. But I'm smart. Looking around, it seems that with ftrace, I am looking for the irqsoff tracer, is that correct? Unfortunately my kernel doesn't have that one: # cat /sys/kernel/debug/tracing/available_tracers blk function_graph mmiotrace wakeup_rt wakeup function nop I can't seem to find any useful information on using perf to analyze ISR latency. Any pointers? Cheers, b.
Attachment:
signature.asc
Description: OpenPGP digital signature
