Re: [PATCH v2] sched/rt: Clean up usage of rt_task()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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