deferring work using kernel threads

[josilton rocha <josilton@xxxxxxxxx>]

Hi,

I am trying to improve the performance of a device
driver.The developer implemented it as a loadable
kernel module.The device notifies the driver of
available incoming data using interrupts. 
The design uses kernel threads as the mechanism to
defer processing from the interrupt handler: 

the interrupt handler merely acknowledges the
interrupt and notifies the kernel thread using a
binary semaphore. The kernel thread waits forever on
the semaphore until it gets notification from the
interrupt handler. 

The device generates about 100,000 interrupts per
second. I stubbed the kernel thread out so everything
it does is to read two 32-bit words from a memory
mapped device every time it receives the interrupt.
Tbhe kernel thread is consuming about 41.5% of the CPU
(a XScale core at 700MHz). 

Although I do intend to do perform some more tests to
validate my assumptions, after reading the chapters
"kernel synchronization methods" and "which bottom
half should I use" of Robert Love's book, it seems to
me that the notification mechanism implemented is not
optimal. 

I would like to hear from an experienced kernel device
driver developer if he some other bottom half
mechanism such as a tasket would not be more suitable
for a data rate of 100,000+ data interrupts/sec. 

Rgds, 
Josilton 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/