On 2025-02-10 14:43:21 [-0500], Steven Rostedt wrote: > On Thu, 6 Feb 2025 14:44:08 +0100 > Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > > 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. > > Does that mean that PREEMPT_RT requires a non preempt method for > SCHED_OTHER for SCHED_OTHER to not hit the issues that we were originally > hitting? That is, with being able to preempt spin_locks in PREEMPT_RT, > running a system with PREEMPT_RT in full preemption mode will still suffer > performance issues against a non PREEMPT_RT running in full preemption mode? So with LAZY_PREEMPT (not that one that was merged upstream, its predecessor) we had a counter similar to the preemption counter. On each rt_spin_lock() the counter was incremented, on each rt_spin_unlock() the counter was decremented. Once the counter hit zero and the lazy preempt flag was set (which was only set on schedule requests by SCHED_OTHER tasks), we scheduled. This improved the performance as we didn't schedule() while holding a spinlock_t and then bump into the same lock in the next task. We don't follow this behaviour exactly today. Adding this behaviour back vs the behaviour we have now, doesn't seem to improve anything at visible levels. We don't have a counter but we can look at the RCU nesting counter which should be zero once locks have been dropped. So this can be used for testing. But as I said: using "run to completion" and preempt on the return userland rather than once the lazy flag is seen and all locks have been released appears to be better. It is (now) possible that you run for a long time and get preempted while holding a spinlock_t. It is however more likely that you release all locks and get preempted while returning to userland. > -- Steve Sebastian
