User:Xdebianx/Workqueue

Introduction
Interrupt handling is a very complex and time critical matter. All Linux interrupt handlers run with their current interrupt line disabled on all processors, moreover some interrupt handlers (known as fast interrupt handlers) run with all interrupts on the local processor disabled. Disabling interrupts in that way ensures that only one processor (and one handler) in a SMP system is called for an interrupt and it also prevents device driver writers from having to handle recursive interrupts, which complicate programming. when an interrupt handler is not enough fast some interrupts can be missed and the entire system can slow down (increasing kernel latency). In order to avoid this inconveniences it is common in Linux kernel programming to split interrupt handling in two halves. The first One is called top-half and the second one bottom-half. In the top-half handler all interrupts are turned off while they are enabled in the bottom-half handler. The bottom half is a routine that is scheduled by the top half to be executed later, at a safer time. Linux 2.6 kernel provides different mechanisms to implement bottom half handlers, one of them are the "workqueue".

Workqueues
Workqueues were introducted with 2.5 Linux Kernel and they are used to schedule the bottom half of an interrupt handler in a safer time. The biggest innovation related to workqueue is that a workqueue runs in a process context. This reason makes workqueue simpler than all other top bottom halves handlers (see tasklets) which work in a interrupt context (a routine running in a interrupt context cannot sleep and consequently it cannot downing a semaphore, copying to or from user-space memory or non-atomically allocating memory). Workqueues are executed by Kernel threads. There is one thread provided the kernel space for each processor present in the system named as events/X that is used to do that. A thread can be also created to manage a specific workqueue whenever a faster execution of the bottom handler is required.

Workqueues vs Tasklet
A comparison between workqueue and tasklet mechanism is provided below


 * Tasklets run software interrupt context (all tasklet are atomic) workqueue functions run in the context of a special kernel process, so they are more flexible (In particular, workqueue functions can sleep).
 * Tasklets always run on the processor from which they were originally submitted but different tasklets run on different CPUs at the same time. Workqueues work in the same way, by default.
 * Tasklet execution time cannot be provided while the execution of workqueue functions can be delayed for an explicit interval by kernel code.
 * Tasklet execution provide a lower kernel latency than workqueue execution.