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

[Sebastian Andrzej Siewior]

On 2026-04-15 07:55:52 [+0200], Christoph Hellwig wrote:
> On Tue, Apr 14, 2026 at 10:23:13AM +0800, Gao Xiang wrote:
> > All softirq IO completion already works like this although
> > softirq tasks are not strictly called "RT tasks" (i.e. a non-RT
> > task issues the IO, and the softirq IO completion will interrupt
> > all ongoing tasks).
> >
> > Basically what we want is to get a non-atomic context instead of
> > using the current softirq context for read post-processing and
> > switch to the task context immediately as you said, because:
> >
> >  - Our post-processing needs to work in task contexts since
> >    advanced features like compression deduplication need it;
> >
> >  - Even regardless of our specific requirement needing task
> >    contexts, using a dedicated task context for read
> >    post-processing is much better than run in the original
> >    softirq context:
> >
> >    - Algorithmic work could take extra time (especially slow
> >      LZMA algorithm could take milliseconds on low devices
> >      (however, we need a common workflow for all algorithms,
> >      including fast algorithms like lz4) and verify work for
> >      example); and long processing time will interfere with
> >      other remaining softirq tasks like sound-playback
> >      / network softirqs;
> >
> >    - If it is then deferred to softirqd, it just makes this
> >      latency issue _worse_.
> 
> Yes, and the same applies to a lot of other things.  A very similar
> algorithmic issue is the checksum validation, be that T10-PI or
> file system native checksums.  We don't want to run them from
> soft/hardirq context obviously, but we really need them to preempt
> other work on the cpu, and avoid scheduling latency.  The case
> that started this is a bit different - folio invalidation mostly
> needs user context to take sleeping locks, but those are usually
> uncontented.  Again, getting this work done ASAP as readers
> are synchronously waiting is important.

Not sure why I ended up here but looking at the patch I don't see how is
different to the kworker solution that is removed. Unless you fiddle
with the thread priority in userland.
The get_cpu() + spin_lock usage breaks on PREEMPT_RT.
The NOHZ_FULL camp might not be happy about putting load on isolated
CPUs. I remember there was some effort to avoid those CPUs.

Sebastian