On 2019-09-16 11:30:30 [+0000], Martin.Wirth@xxxxxx wrote: > Hi Sebastian, Hi Martin, > 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? If something is automatically converted then we need to disable the softirq while invoking the handler. This was also the case before force-threading and the interrupt thread may assume such behaviour. If you explicitly request a threaded IRQ then there is no such need because the handler knows what it does and should disable softirq on its own if needed. Due to the softirq rework we can't have multiple softirqs vectors running in parallel _or_ have multiple local_bh_disable() section which are executed in parallel on the same CPU. This made the softirq code not only simpler but also allowed us to remove a little bit duct tape from places which were expecting this kind of behaviour. In the long term we need to figure out if we want to go down that road again and if so we need to figure out how to avoid that duct tape… > Martin Sebastian
