Paul! On Mon, Dec 04 2023 at 17:33, Paul E. McKenney wrote: > On Tue, Nov 28, 2023 at 06:04:33PM +0100, Thomas Gleixner wrote: >> So: >> >> loop() >> >> preempt_disable(); >> >> --> tick interrupt >> rcu_flavor_sched_clock_irq() >> sets NEED_RESCHED >> >> preempt_enable() >> preempt_schedule() >> schedule() >> report_QS() >> >> See? No magic nonsense in preempt_enable(), no cond_resched(), nothing. > > Understood, but that does delay detection of that quiescent state by up > to one tick. Sure, but does that really matter in practice? >> So if that turns out to matter in reality and not just by academic >> inspection, then we are far better off to annotate such code with: >> >> do { >> preempt_lazy_disable(); >> mutex_lock(); >> do_stuff(); >> mutex_unlock(); >> preempt_lazy_enable(); >> } >> >> and let preempt_lazy_enable() evaluate the NEED_RESCHED_LAZY bit. > > I am not exactly sure what semantics you are proposing with this pairing > as opposed to "this would be a good time to preempt in response to the > pending lazy request". But I do agree that something like this could > replace at least a few more instance of cond_resched(), so that is good. > Not necessarily all of them, though. The main semantic difference is that such a mechanism is properly nesting and can be eventually subsumed into the actual locking constructs. >> Just insisting that RCU_PREEMPT=n requires cond_resched() and whatsoever >> is not really getting us anywhere. > > Except that this is not what is happening, Thomas. ;-) > > You are asserting that all of the cond_resched() calls can safely be > eliminated. That might well be, but more than assertion is required. > You have come up with some good ways of getting rid of some classes of > them, which is a very good and very welcome thing. But that is not the > same as having proved that all of them may be safely removed. Neither have you proven that any of them will be required with the new PREEMPT_LAZY model. :) Your experience and knowledge in this area is certainly appreciated, but under the changed semantics of LAZY it's debatable whether observations and assumptions which are based on PREEMPT_NONE behaviour still apply. We'll see. Thanks, tglx