Hi, I refer below thread for interrupt polling related discussion for storage devices (NVME/HBA). http://lists.infradead.org/pipermail/linux-nvme/2017-January/007749.html I am trying to evaluate the similar concept to reduce interrupts using irq-poll and threaded ISR. Below is high level changes I did in my experiment. In megaraid_sas driver, I schedule irq poll using “irq_poll_sched” and disable that particular IRQ line. I was expecting more completion after I disable irq line, but in most of the cases just one completion happened from irq poll context. It must be due to host side processing is much faster than IO processing at back end device. Similar observation was posted in above mentioned thread as well. I added manual wait using “udelay()” and wait for some more time in irq poll context. Using additional wait, I am able to reduce interrupt per seconds and performance impact on latency is not visible since I choose udelay(1). One drawback I see is overall CPU utilization goes up since driver is using extra delay to reduce interrupts. To overcome CPU utilization issue, I switch to threaded ISR and replace udelay() with usleep(). Using threaded interrupt based polling CPU utilization goes to normal. I am trying to understand what is a drawback using threaded ISR and doing interrupt polling from threaded ISR. One problem I understood is threaded ISR can be preempted by other high priority context (most likely soft/hard interrupt). If threaded interrupt is running on some CPU-x and some other device is also requesting interrupt on same CPU-x, there can be latency introduced because CPU-x will complete ISR before it can run threaded ISR. Thanks, Kashyap
