On Fri, Mar 22, 2024 at 09:02:02PM -0500, Yan Zhai wrote: > 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? Removing the "IS_ENABLED(CONFIG_PREEMPT_RT)" condition makes a great deal of sense to me, but I must defer to Sebastian for any RT implications. Thanx, Paul
