[lkml]   [2019]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 <> wrote:

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

 \ /
  Last update: 2019-07-26 23:31    [W:0.104 / U:3.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site