Linux External Event Handling - IRQ vs. Polling kthread - linux

Question

I am porting a device driver from QNX to Linux. In QNX, the old driver used a pthread with an infinite loop to monitor for the occurrence of an interrupt, rather than registering a true interrupt handler. To try to demonstrate the efficacy of using register_irq() instead of a dedicated polling thread, I wrote two drivers in Linux. The relevant code for each is shown below and the question is at the bottom.
IRQ
Write the handler
irqreturn_t timing_interrupt_handler(int irq, void *dev_id) {
u32 test;
/* read device interrupt command/status register */
test = ioread32(timing_card[3].base);
/* sanity check that the device reported the interrupt */
if ( test & (1 << 2) ) {
/* clear interrupt status */
iowrite32( 0x0d, timing_card[3].base);
/* toggle digital output line */
test = ioread32(timing_card[2].base);
if ( test & 0x01 )
iowrite32(test & ~0x1, timing_card[2].base);
else
iowrite32(test | 0x1, timing_card[2].base);
}
return IRQ_HANDLED;
}
Register the handler
rc = request_irq(irq_line, timing_interrupt_handler,
IRQF_SHARED, "timing", timing_card);
if ( rc ) {
printk(KERN_ALERT "Failed to register irq %d\n", irq_line);
return rc;
}
POLLING THREAD
Write the thread function
int poll_irq(void *data) {
u32 test;
/* until module unload */
while ( !kthread_should_stop() ) {
/* read device interrupt command/status register */
test = ioread32(timing_card[3].base);
/* sanity check that the device reported the interrupt */
if ( test & (1 << 2) ) {
/* clear interrupt status */
iowrite32( 0x0d, timing_card[3].base);
/* toggle digital output line */
test = ioread32(timing_card[2].base);
if ( test & 0x01 )
iowrite32(test & ~0x1, timing_card[2].base);
else
iowrite32(test | 0x1, timing_card[2].base);
}
else
usleep_range(9, 11);
}
return 0;
}
Begin the thread
kthread = kthread_create(poll_irq, 0x0, "poll_IRQ_test");
wake_up_process(kthread);
THE QUESTION
When I put two traces on an oscilloscope - one monitoring the card's digital input (which would trigger the interrupt) and one monitoring the card's digital output (which would react to the interrupt) I can measure the reaction time to an event.
The first "proper" method, registering an IRQ, takes approximately 80 microseconds.
The second method, running an infinite thread, takes approximately 15-30 microseconds.
What gives? The benefit of the first is that it doesn't waste as much processing power, but why does response time suffer so dramatically? How bad is it, really, to have this polling thread? How could one go about investigating and eventually demonstrating the extra toll the polling thread puts on the CPU?
Thanks for your time!
Best
Scott

Answer 1

The interrupt response time is affected by the time your system (whatever it is) needs to deliver the interrupt, and by the time your CPU (whatever it is) needs to wake up from some power-saving sleeping mode.
The polling thread eats both CPU time and power.
To measure them, use something like top or powertop, or measure the power consumption directly on the hardware.