Hi Jeffrey, On Mon, 7 Dec 2020 at 16:48, Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote: > > On 12/7/2020 6:20 AM, Loic Poulain wrote: > > Hi folks, > > > > Before putting my hands into that, I wanted to expose a MHI interrupt > > problem, comments are welcome. > > > > Currently, the hard IRQ handler for event rings do nothing except > > triggering a tasklet as bottom half that in turn will take care of > > retrieving buffer(s). That leads to have an unexpected high amount of > > interrupts when I perform throughput testing with mhi-net (though it > > applies for any mhi client driver). > > > > The point is that usually, an hard interrupt handler is responsible > > for triggering the bottom half handler but also for > > clearing/suspending interrupt on device side. However, AFAIK, there is > > no such possibility in the MHI protocol. Since the interrupt is not > > I think Linux side improvements would always be welcome, but have you > looked at BEI and INTMODT? They are features defined in the MHI spec > for addressing interrupt storms. Yes, that interrupt coalescing feature is working well, and I use it in that context. But Actually the problem is not really that the device generates too many interrupts, but that the driver does not mask the interrupt while handling it, causing replicated interrupts, and so useless hard interrupt handler executions. I need to investigate how bad it impact the system/transfers though. > > > > handled in the hard irq handler, it is triggered again once interrupt > > are re-enabled, and even during the tasklet execution... at the end, > > that makes a lot of unnecessary interrupts, that introduce latency and > > participate to system load... > > > > I added some printk to highlight that issue: > > [11564.689202] mhi_irq_handler 55d32b8 > > [11564.689485] mhi_irq_handler 55d32b8 > > [11564.690011] mhi_irq_handler 55d32b8 > > [11564.690397] [55d32b8] mhi_process_data_event_ring start > > [11564.690667] mhi_irq_handler 55d32b8 > > [11564.690937] mhi_irq_handler 55d32b8 > > [11564.691207] mhi_irq_handler 55d32b8 > > [11564.691475] mhi_irq_handler 55d32b8 > > [11564.692076] [55d32b8] mhi_process_data_event_ring done > > [...] > > > > I see two solutions to fix that problem: > > - Manage events directly in the hard-irq handler (no more tasklet) > > - Use threaded IRQ with IRQF_ONESHOT flag, to keep interrupt masked > > until threaded handler has completed. > > > > Regards, > > Loic
