On Fri, 26 Jul 2019 21:16:24 +0000
Julia Cartwright <[email protected]> wrote:
> > + if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> > + if (task_is_realtime(current) && !(mode & HRTIMER_MODE_SOFT))
> > + mode |= HRTIMER_MODE_HARD;
>
> Because this ends up sampling the tasks' scheduling parameters only at
> the time of enqueue, it doesn't take into consideration whether or not
> the task maybe holding a PI lock and later be boosted if contended by an
> RT thread.
>
> Am I correct in assuming there is an induced inversion here in this
> case, because the deferred wakeup mechanism isn't part of the PI chain?
>
> If so, is this just to be an accepted limitation at this point? Is the
> intent to argue this away as bad RT application design? :)
>
Well, it shouldn't be holding any kernel PI locks (aka spin_lock) when
it sleeps, but may be holding a PI futex. In which case, I would say is
a bad RT application, to have a thread sleep on a non RT timer while
holding a lock that an RT Task might take.
-- Steve
