Hi Sebastian, > Von: Sebastian Andrzej Siewior [mailto:bigeasy@xxxxxxxxxxxxx] > Gesendet: Freitag, 13. September 2019 17:07 > puh. So you need to specify IRQF_ONESHOT so that the IRQ-core disables > the interrupt line until the threaded handler finishes its work (a > detail I forgot to mention in the previous mail). You are not allowed to > mix the IRQF_ONESHOT flag with multiple handlers (either all should have > them or none). So I think in the force-threaded case you should be fine > but in the non-threaded case you would have trouble. I tried the request_threaded_irq(.., vInterruptService, IRQF_SHARED|IRQF_ONESHOT, ...) variant and indeed the latency spikes caused by concurrent disk-io go away!! So I now have a working solution for me and also learned how to separate interrupts using /proc/irq as a second option to cope with this problem. But in general I find it not very transparent that with the latest changes softirq work can block higher priority irq threads for several ms or maybe even longer and nothing can be done against it with normal RT control-knobs, but a change to the driver code is required. Isn't there an automatic way to decide, when it is possible to convert a request_irq to a request_threaded_irq? Martin
