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

[Sandeep Dhavale]

> 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.