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

[Christoph Hellwig <hch@lst.de>]

[adding the workqueue maintainers that I should have added]

On Wed, Apr 15, 2026 at 07:48:35AM +0200, Christoph Hellwig wrote:
> 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.
---end quoted text---