1

I'm just reading about Linux kernel interrupt handler bottom halves for the first time, and am trying to understand the use of the work queue for deferred work.

From what I understand, the benefit of the work queue over softirps or tasklets is that the work is done in process context so it can sleep. But by default, this work is just done sequentially on one of the events/X threads? So if say some work is started on events/0 which then sleeps for a long time waiting on some IO, no more work queue items can be processed on that processor, which seems pretty terrible for performance.

So is the onus just on all interrupt handler developers to not use the default events/X thread if the work could sleep for a long time? Or have I misunderstood something?

j0k
  • 22,600
  • 28
  • 79
  • 90
toprice
  • 11
  • 1
  • 2

1 Answers1

1

But by default, this work is just done sequentially on one of the events/X threads? So if say some work is started on events/0 which then sleeps for a long time waiting on some IO, no more work queue items can be processed on that processor, which seems pretty terrible for performance.

This is not accurate; workqueue API allows both single-threaded, and multi-threaded tasks. for the former, the function create_singlethread_workqueue() is called.

So is the onus just on all interrupt handler developers to not use the default events/X thread if the work could sleep for a long time? Or have I misunderstood something?

In softirq (i.e. tasklet) you cannot sleep at all, so basically, the benefit of workqueue is that you can sleep.. indeed - it's the developer responsibility not to cause other kthreads to starve in case of singlethread workqueue.

Also bear in mind, that workqueue API provides more than just enqueue/dequeue of tasks, but also provides functions to queue delayed work, sync between works, flush work queues, cancel delayed works, etc.. this API is also an advantage over other softirq-based libraries, even for non-sleep'able usage.

LIUB
  • 354
  • 1
  • 7