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/
