Search code examples
linux-kerneldevice-driverlinux-device-driver

tasklet advantage in userspace application


Got some doubts with bottom half.Here, I consider tasklets only. Also , I consider non-preemptible kernel only.

Suppose consider a ethernet driver in which rx interrupt processing is doing some 10 functions calls.(bad programming :) )

Now, looking at performance perspective if 9 function calls can be moved to a tasklet and only 1 needs to be called in interrupt handling , Can I really get some good performance in a tcp read application.

Or in other words, when there is switch to user space application all the 9 function calls for the tasklets scheduled will be called, in effective the user space application will be able to get the packet cum data only after "all the taskets scheduled" are completed ? correct?

I understand that by having bottom half , we are enabling all interrupts .. but I have a doubt whether the application that relies on the interrupt actually gain anything by having the entire 10 functions in interrupt handler itself or in the bottom half.

In Short, by having tasklet do I gain performance improvement in user space application ,here ?


Solution

  • Since tasklets are not queued but scheduled, i.e. several hardware interrupts posting the same tasklet might result in a single tasklet function invocation, you would be able to save up to 90% of the processing in extreme cases.

    On the other hand there's already a high-priority soft IRQ for net-rx.