On 2019-09-03 07:23:35 [+0000], Martin.Wirth@xxxxxx wrote: > Hi, Hi, … > /proc/irq interface the latencies are gone. The real-time priority of the digitizer IRQ handler > is set to 53 and that of the corresponding user space thread to 51. The ahci interrupt > thread is at the standard value of 50. > > Although I now have the solution to put the ahci-handler on a different processor, I would > like to know if it is expected behavior that the ahci interrupt handler blocks other interrupt > threads of higher priority for more than one millisecond? Based on the CPU split via proc/irq you describe here I assume that both devices (ahci and the digitizer cards) do not share an interrupt line. In that case both handlers are independent and should not affect each other. Running on the same CPU, the AHCI handler can be interrupt by another thread (with a higher priority) if that interrupt line was raised while the AHCI handler was active. So based on that, the "digitizer IRQ handler" should run first, followed by the user space thread, followed by the AHCI interrupt. > Another observation which I cannot understand though, is that a concurrent > cyclictest -m -Sp98 -i200 -h400 -n > run does not show the latencies... you have here "-p98" while the other two threads have priority 53 and 51. So that is a difference unless there is nothing between 53 and 51. But if you disable the "digitizer card(s)" then with -p51 you should be close to that setup with cyclictest. If there are no spikes in cyclictest then there must be something after the threaded handler runs that delays the user space task. Some tracing should help to figure out what happens between the hardware interrupt and the context switch to the user task. > Cheers, > > Martin Sebastian
