On Thu, 6 Feb 2025 14:57:44 +0100
Peter Zijlstra <pet...@infradead.org> wrote:
> Right, but so what? Same delay will happen if interrupt fires in the
> middle of a preempt_disable() region.
>
> Or if interrupt gets pending while interrupts are disabled, except your
> trace will not show that.
>
> Your worst case response time isn't affected. That's all that matters.
So now if a task has this set, and an interrupt goes off and wakes an RT
task, not only is the time of the interrupt the latency of the RT task, but
also this extension of the SCHED_OTHER task.
That is, where it use to be:
event RT task scheduled
| |
v v
time: |-------+-+----+--
^
|
interrupt
If the interrupt triggered just as the task set this bit, we then have:
event set Xus RT task scheduled
| | |
v v v
time: |-------+-+----+-------+--+
^ ^
| |
interrupt Xus timer triggered
This adds on *top* of the current latency, and is not just by itself.
Yes, this may not happen often, but in RT we very much do care about the
worst case scenarios. (That's the difference between an RT project and a
project that just uses RT).
-- Steve
