On 2024-05-27 18:26:50 [+0100], Qais Yousef wrote: > > In order to be PI-boosted you need to acquire a lock and the only lock > > you can sleep while acquired without generating a warning is a mutex_t > > (or equivalent sleeping lock) on PREEMPT_RT. > > Note we care about the behavior for !PREEMPT_RT. PI issues are important there > too. I assume the fact the PREEMPT_RT changes the locks behavior is what you're > referring to here and not applicable to normal case. So for !PREEMPT_RT you need a rtmutex for PI. RCU and i2c is using it within the kernel and this shouldn't go via the `slack' API. The FUTEX API on the other hand is a different story and it might matter. So you have one task running SCHED_OTHER and acquiring a lock in userspace (pthread_mutex_t, PTHREAD_PRIO_INHERIT). Another task running at SCHED_FIFO/ RR/ DL would also acquire that lock, block on it and then inherit its priority. This is the point where the former task has a different policy vs priority considering PI-boosting. You could argue that the task shouldn't sleep or invoke anything possible sleeping with a timeout > 0 because it is using an important lock. But then it is userland and has the freedom to do whatever it wants you know… So it might be better to forget what I said and keeping the current behaviour. But then it is insistent which matters only in the RT case. Puh. Any sched folks regarding policy? > Thanks! Sebastian
