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

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/4/11 06:11, Dave Chinner wrote:
> On Thu, Apr 09, 2026 at 06:02:21PM +0200, Christoph Hellwig wrote:
>> Commit 3fffb589b9a6 ("erofs: add per-cpu threads for decompression as an
>> option") explains why workqueue aren't great for low-latency completion
>> handling.  Switch to a per-cpu kthread to handle it instead.  This code
>> is based on the erofs code in the above commit, but further simplified
>> by directly using a kthread instead of a kthread_work.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> 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...

It has been "fixed" but never actually get fixed:
https://lore.kernel.org/r/CAB=BE-QaNBn1cVK6c7LM2cLpH_Ck_9SYw-YDYEnNrtwfoyu81Q@mail.gmail.com

and workqueues don't have any plan to introduce RT threads;

If Sandeep has more time, I hope he could have more time to
test since I don't work on Android anymore: In principle,
I still think RT thread is needed somewhere for such usage
since lowest latencies is needed.

Compared to the scheduling latency issues, interested users
don't care "individual subsystems needing their own set of
per-cpu kernel tasks just sitting around idle most of of
the time". If end users care it more, they can just turn
it off by Kconfig.

If you think it's unclean to block subsystems, I'm fine to
leave it as-is.  I'm not sure how it impacts to others:
either some subsystems implement RT threads (workqueue or
block), or leave it as-is; Otherwise there is always such
latency issues and unacceptable for end users.

Thanks,
Gao Xiang


> 
> -Dave.
>