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

Sebastian Andrzej Siewior
2026-04-15T06:30:55Z

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