On 2024-05-29 11:34:09 [+0100], Qais Yousef wrote: > > 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? Right now a SCHED_OTHER task boosted to a realtime priority gets slack=0. In the !RT scenario everything is fine. For RT the slack=0 also happens but the init of the timer looks at the policy instead at the possible boosted priority and uses a different clock attribute. This can lead to a delayed wake up (so avoiding the slack does not solve the problem). This is not consistent because IMHO the clock setup & slack should be handled equally. So I am asking the sched folks for a policy and I am leaning towards looking at task-policy in this case instead of prio because you shouldn't do anything that can delay. Sebastian