The MHI interrupt handling issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux