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.
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
-- Jeffrey Hugo Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
