On 05/29/24 10:29, Sebastian Andrzej Siewior wrote: > 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… Yes.. > > So it might be better to forget what I said and keeping the current Okay I'll drop the patch then in next posting. > behaviour. But then it is insistent which matters only in the RT case. > Puh. Any sched folks regarding policy? I am not sure I understood you here. Could you rephrase please?
