Re: Long latencies during disk-io

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2019-09-03 07:23:35 [+0000], Martin.Wirth@dlr.de 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