Re: [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support

[Christoph Hellwig <hch@lst.de>]

On Sat, Apr 11, 2026 at 08:11:22AM +1000, Dave Chinner wrote:
> Can we please not go back to the (bad) old days of individual
> subsystems needing their own set of per-cpu kernel tasks just
> sitting around idle most of of the time?  The whole point of the
> workqueue infrastructure was to get rid of this widely repeated
> anti-pattern.
> 
> If there's a latency problem with workqueue scheduling, then we
> should be fixing that problem rather than working around it in every
> subsystem that thinkgs it has a workqueue scheduling latency
> issue...

Fixing the workqueue scheduling would be nice, but the attempts so far
failed.

In addition to that for a lot of theses cases workqueues are actually a
surprisingly bad fit - we have items we want to queue up an one single
function to call on all of them.  So the overhead should be a list item
(which often can be singly linked) in the object, while the workqueue
also adds flags and a function pointer, bloating the size. We often work
around this by having a single work_struct work on multiple objects, but
that just increases the amount of work that needs to be done, including
atomics and scheduling.

Last but not least bio completion isn't really any random subsystem.
Block I/O completion is important enough that we have an even more
epensive softirq allocated to it.  I agree that the dynamic
workqueue-style workers are a much better choise for most use cases,
though.