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

Sandeep Dhavale
2026-04-15T12:50:11Z

> 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, this was the reasoning when I narrowed it down to per-CPU
kthread approach. Patch has helped reduce app launch times which
has a direct user impact.

>
> But anyway, I think nice -19 can be evaluated if Sandeep have time,
> but such nice value should be set by the filesystem instead of
> the userspace since the reason is as above.
>

I will find some time to re-do this again, including setting nice -19.

-Sandeep.