Messages in this thread | | | Date | Fri, 26 Jul 2019 17:30:52 -0400 | From | Steven Rostedt <> | Subject | Re: [patch 10/12] hrtimer: Determine hard/soft expiry mode for hrtimer sleepers on RT |
| |
On Fri, 26 Jul 2019 21:16:24 +0000 Julia Cartwright <julia@ni.com> 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
| |