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

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

On 2026/4/11 07:44, Gao Xiang wrote:
> 
> 
> 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

^ Implement dedicated queues somewhere using
sched_set_fifo_low() for such latency-sensitive work.

> latency issues and unacceptable for end users.
> 
> Thanks,
> Gao Xiang
> 
> 
>>
>> -Dave.
>>
>