On 2025-02-06 08:30:39 [-0500], Steven Rostedt wrote: > NEED_RESCHED_LAZY was introduced to remedy this. It would be set for > SCHED_OTHER tasks and NEED_RESCHED for RT tasks. If the task was holding > a sleeping spin lock, the NEED_RESCHED_LAZY would not preempt the running > task, but NEED_RESCHED would. If the SCHED_OTHER task was not holding a > sleeping spin_lock it would be preempted regardless. > > This improved the performance of SCHED_OTHER tasks in PREEMPT_RT to be as > good as what was in vanilla. > > You see, LAZY was *created* for this purpose. Of letting the scheduler know > that the running task is in a critical section and the timer tick should > not preempt a SCHED_OTHER task. This was introduced that way originally. It helped because we did not preempt lock-owner unless we had to. This isn't the case with LAZY as of today. I did add a scheduling point in rt_spin_unlock() if LAZY was set and based on few tests it was something between noise and worse. It seems that "run to completion" is better than interrupt the kernel in the middle whatever it is doing. "Don't preempt the lock owner" is already handled by LAZY with the scheduling point on return to userland. > I just wanted to extend this to SCHED_OTHER in user space too. > > > > > Yes, I have worked on RT projects before -- you would know better > > than anyone. :-D. But admittedly, I haven't got to work much with > > PREEMPT_RT systems. > > Just using RT policy to improve performance is not an RT project. I'm > talking about projects that if you miss a deadline things crash. Where the > project works very hard to make sure everything works as intended. > > I'm totally against allowing SCHED_OTHER to use any feature that can delay > an RT/DL task (unless of course it is to help those, like priority inheritance). > > There's several RT folks on this thread. I wonder if any of > them are OK with this? If you roll your own (sched_ext) then do what you want as per you sched-policy. If you use this LAZY bit as a hint from userland to kernel as "please give me up to X usec/ ticks before cutting me off" fine. It is SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of SCHED_FIFO/ RR/ DL because of this LAZY hint. > -- Steve Sebastian
