On Fri, Mar 22, 2024 at 4:31 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Fri, Mar 22, 2024 at 12:24:13PM +0100, Sebastian Andrzej Siewior wrote: > > On 2024-03-19 13:44:34 [-0700], Yan Zhai wrote: > > > + * The macro is not needed when CONFIG_PREEMPT_RT is defined. RT kernels would > > > + * have more chance to invoke schedule() calls and provide necessary quiescent > > > + * states. As a contrast, calling cond_resched() only won't achieve the same > > > + * effect because cond_resched() does not provide RCU-Tasks quiescent states. > > > + */ > > > > Paul, so CONFIG_PREEMPTION is affected but CONFIG_PREEMPT_RT is not. > > Why does RT have more scheduling points? > > In RT, isn't BH-disabled code preemptible? But yes, this would not help > RCU Tasks. > By "more chance to invoke schedule()", my thought was that cond_resched becomes no op on RT or PREEMPT kernel. So it will not call __schedule(SM_PEREEMPT), which clears the NEED_RESCHED flag. On a normal irq exit like timer, when NEED_RESCHED is on, schedule()/__schedule(0) can be called time by time then. __schedule(0) is good for RCU tasks, __schedule(SM_PREEMPT) is not. But I think this code comment does not take into account frequent preempt_schedule and irqentry_exit_cond_resched on a PREEMPT kernel. When returning to these busy kthreads, irqentry_exit_cond_resched is in fact called now, not schedule(). So likely __schedule(PREEMPT) is still called frequently, or even more frequently. So the code comment looks incorrect on the RT argument part. We probably should remove the "IS_ENABLED" condition really. Paul and Sebastian, does this sound reasonable to you? Yan
