On Sun, Apr 30, 2023 at 03:56:11PM -0400, Joel Fernandes wrote: > Hello, > Quick question (for educational purpose) for anyone - why does > PREEMPT=n kernel not want to get help from __rcu_read_unlock() for > expedited grace periods? > > Basically, with PREEMPT=y kernels, rcu_read_unlock_special.b.exp_hint > is set to true, but for PREEMPT=n, no such thing is done. Furthermore, > the __rcu_read_unlock() for PREEMPT=n does not help expedited GPs come > to an end either. > > I am guessing the answer is, "no one cares about that", or "no one > reported needing this", but if there is another reason why a PREEMPT=n > kernel should not need it, do let me know :) Because PREEMPT=n kernels value fast rcu_read_unlock() more than they value fast expedited grace periods. > To make it more interesting, it appears that CONFIG_PREEMPT=y where > preemption is dynamically disabled, it _should_ have the effect of > helping expedited GPs as far as I can see. Which further seems a > difference between booting PREEMPT=n versus PREEMPT=y + booting with > preemption turned off via boot option. Yes, very much so! So if you care deeply about fast expedited grace periods and less so about smallish rcu_read_unlock() slowdowns, but otherwise want non-preemptibility, CONFIG_PREEMPT_DYNAMIC=y and dynamically selecting non-preemptible operation might be your best choice. Thanx, Paul
