Re: task queues

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

   Date: Sat, 26 Jul 2014 17:00:18 +0100
   From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>

   Not against the idea, but frankly - the implementation looks somewhat
   over-engineered.

Most of the engineering in the implementation went into satisfying the
request you made in private to limit the number of kthreads involved.
I could make a much simpler implementation that does not pool
kthreads, but you objected to that.

   Why not to extend the workqueue(9) interface in the first place?

workqueue(9) is more fiddly than most users of it want.  Half of what
I hear about workqueues is `argh, why are they so painful to use?'.  I
don't hear that about usb_task(9), which is basically a specialization
of task(9).  However, usb_task(9) needs some help: e.g., usb_rem_task
doesn't to wait for a task to complete and there's no way to do that.
Plus as implemented it doesn't scale, and there's no reason for it to
be specific to the USB stack.

I surveyed all the users of workqueue(9) in-tree and found that the
vast majority involve a workqueue for a single purpose with a single
associated struct work, while some (e.g., ffs TRIM support) have a
bunch of extra support code to drain their workqueue, and others
(e.g., bcm53xx_eth) use both workqueues and softints only to adjust
scheduling priorities and for no other obvious reason.  All of these
uses are more easily and more scalably served by task(9).