On Tue, 4 Feb 2025 10:16:13 +0100 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > And yes, you can still use the whole 'delay preemption' hint for RT > tasks just fine. Spinlocks isn't the only thing. It can be used to make > any RSEQ section more likely to succeed. > > > > Patch 2 changes that to do what you wrote the last time. It has a max wait > > time of 50us. > > I'm so confused, WTF do you then need the lazy crap? > > You're making things needlessly complicated again. Do we really want to delay an RT task by 50us? That will cause a lot more regressions. This is a performance feature not a latency one. RT tasks are about limiting latency and will sacrifice performance to do so. PREEMPT_RT has great minimal latency at the expense of performance. We try to improve performance but never at the sacrifice of latency. RT wakeups are also more predictable. That is, they happen when an event comes in or a timer expires and when an RT task wakes up it is to run ASAP to handle some event. This is about SCHED_OTHER tasks where the scheduler decides when a task gets to run and will preempt it when its quota is over. The task has no idea when that will happen. This is about giving the kernel a hint that it's a bad time to interrupt the task and if it can just wait another 50us or less, then it would be fine to schedule. SCHED_OTHER tasks never have latency requirements less than a millisecond. And SCHED_OTHER tasks are effected by other SCHED_OTHER tasks, even those that are lower priority. My patches here were based on where the NEED_RESCHED_LAZY came from, and that was from the PREEMPT_RT patch. The problem was that the kernel would allow preemption almost everywhere. This was great for RT tasks, but non RT tasks suffered performance issues. That's because of the timer tick going off while a SCHED_OTHER task was holding a spin_lock converted into a mutex and it would be scheduled out while holding that sleeping spin_lock. This increased the amount of contention on that spin_lock, and that affected performance. The fix was to introduce NEED_RESCHED_LAZY which would not have the SCHED_OTHER task preempt while holding a sleeping spin_lock. This put back the performance close to non PREEMPT_RT. This work I'm doing is based on that. It doesn't make sense to delay RT tasks for a performance improvement. -- Steve
