On Sun, Aug 11, 2019 at 09:40:53PM -0400, Joel Fernandes wrote: > On Sun, Aug 11, 2019 at 09:24:31PM -0400, Joel Fernandes wrote: > > On Sun, Aug 11, 2019 at 04:30:24PM -0700, Paul E. McKenney wrote: > [snip] > > > Next question: Why does rcu_implicit_dynticks_qs() check only for > > > tick_nohz_full_cpu() and not also IS_ENABLED(CONFIG_PREEMPT)? After > > > all, a nohz_full CPU in a !CONFIG_PREEMPT kernel should be able to > > > rely on cond_resched(), right? > > > > > > Should this change? Why or why not? > > > > Let me think more about this :) I have an answer in mind but I will think a > > bit more about it and responsd :) > > It should not change. That's because (as somewhat mentioned in the comments), > some code paths in the kernel check need_resched() before invoking > cond_resched(). So even with PREEMPT=n having the help of cond_resched(), the > cond_resched() may actually not even be invoked. So in this case, the > resched_cpu() from rcu_implicit_dynticks_qs() does the needful by setting the > rescheduling flags on the CPU, so that cond_resched() on those CPUs actually > get called. Is that a correct analysis? Looks valid to me! There might well be other scenarios as well, but only one is required to justify the resched_cpu(). Thanx, Paul
