On Fri, Apr 08, 2022 at 11:39:46AM -0400, Steven Rostedt wrote: > On Fri, 8 Apr 2022 06:21:03 -0400 > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > > > + default !PREEMPT_RT && NR_CPUS <= 32 > > > > What is the benefit of turning it off on PREEMPT_RT, even if > > PREEMPT_RT does not use expedited GPs much post-boot? I would think in > > the future if PREEMPT_RT ever uses expedited GPs, they would want this > > feature even more. I'd rather be future-proof now as I don't see any > > advantages of disabling it on !PREEMPT_RT (And a drawback that the fix > > won't apply to those systems). Also will keep the config simple. > > The default kthread priority is 1. This should not affect PREEMPT_RT, as > PREEMPT_RT users are usually more concerned by the performance of their > higher priority tasks. Priority 1 is not considered an issue. > > I do not see why PREEMPT_RT is special here. Why was it singled out? Because I didn't see the point of doing kthread_create_worker() to create a pair of kthread_worker structuress that were never going to be used in PREEMPT_RT kernels. Or are PREEMPT_RT kernels no longer booting with rcupdate.rcu_normal? Last I knew, they all did this to avoid IPI latencies from expedited grace periods. Has this changed? Thanx, Paul
