Paul E. McKenney <paulmck@xxxxxxxxxx> writes: > On Fri, Oct 20, 2023 at 03:56:38PM -0700, Ankur Arora wrote: >> >> Paul E. McKenney <paulmck@xxxxxxxxxx> writes: >> >> > Thomas! >> > >> > On Thu, Oct 19, 2023 at 02:21:35AM +0200, Thomas Gleixner wrote: >> >> Paul! >> >> >> >> On Wed, Oct 18 2023 at 10:19, Paul E. McKenney wrote: >> >> > On Wed, Oct 18, 2023 at 03:16:12PM +0200, Thomas Gleixner wrote: >> >> >> On Tue, Oct 17 2023 at 18:03, Paul E. McKenney wrote: >> >> >> In the end there is no CONFIG_PREEMPT_XXX anymore. The only knob >> >> >> remaining would be CONFIG_PREEMPT_RT, which should be renamed to >> >> >> CONFIG_RT or such as it does not really change the preemption >> >> >> model itself. RT just reduces the preemption disabled sections with the >> >> >> lock conversions, forced interrupt threading and some more. >> >> > >> >> > Again, please, no. >> >> > >> >> > There are situations where we still need rcu_read_lock() and >> >> > rcu_read_unlock() to be preempt_disable() and preempt_enable(), >> >> > repectively. Those can be cases selected only by Kconfig option, not >> >> > available in kernels compiled with CONFIG_PREEMPT_DYNAMIC=y. >> >> >> >> Why are you so fixated on making everything hardcoded instead of making >> >> it a proper policy decision problem. See above. >> > >> > Because I am one of the people who will bear the consequences. >> > >> > In that same vein, why are you so opposed to continuing to provide >> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code >> > is already in place, is extremely well tested, and you need to handle >> > preempt_disable()/preeempt_enable() regions of code in any case. What is >> > the real problem here? >> [ snip ] >> As far as I can tell (which isn't all that far), TREE_RCU=y makes strictly >> stronger forward progress guarantees with respect to rcu readers (in >> that they can't be preempted.) > > TREE_RCU=y is absolutely required if you want a kernel to run on a system > with more than one CPU, and for that matter, if you want preemptible RCU, > even on a single-CPU system. > >> So, can PREEMPTION=y run with, say TREE_RCU=y? Or maybe I'm missing something >> obvious there. > > If you meant to ask about PREEMPTION and PREEMPT_RCU, in theory, you > can run any combination: Sorry, yes I did. Should have said "can PREEMPTION=y run with, (TREE_RCU=y, PREEMPT_RCU=n). > PREEMPTION && PREEMPT_RCU: This is what we use today for preemptible > kernels, so this works just fine (famous last words). > > PREEMPTION && !PREEMPT_RCU: A preemptible kernel with non-preemptible > RCU, so that rcu_read_lock() is preempt_disable() and > rcu_read_unlock() is preempt_enable(). This should just work, > except for the fact that cond_resched() disappears, which > stymies some of RCU's forward-progress mechanisms. And this > was the topic of our earlier discussion on this thread. The > fixes should not be too hard. > > Of course, this has not been either tested or used for at least > eight years, so there might be some bitrot. If so, I will of > course be happy to help fix it. > > > !PREEMPTION && PREEMPT_RCU: A non-preemptible kernel with preemptible > RCU. Although this particular combination of Kconfig > options has not been tested for at least eight years, giving > a kernel built with CONFIG_PREEMPT_DYNAMIC=y the preempt=none > kernel boot parameter gets you pretty close. Again, there is > likely to be some bitrot somewhere, but way fewer bits to rot > than for PREEMPTION && !PREEMPT_RCU. Outside of the current > CONFIG_PREEMPT_DYNAMIC=y case, I don't see the need for this > combination, but if there is a need and if it is broken, I will > be happy to help fix it. > > !PREEMPTION && !PREEMPT_RCU: A non-preemptible kernel with non-preemptible > RCU, which is what we use today for non-preemptible kernels built > with CONFIG_PREEMPT_DYNAMIC=n. So to repeat those famous last > works, this works just fine. > > Does that help, or am I missing the point of your question? It does indeed. What I was going for, is that this series (or, at least my adaptation of TGLX's PoC) wants to keep CONFIG_PREEMPTION in spirit, while doing away with it as a compile-time config option. That it does, as TGLX mentioned upthread, by moving all of the policy to the scheduler, which can be tuned by user-space (via sched-features.) So, my question was in response to this: >> > In that same vein, why are you so opposed to continuing to provide >> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code >> > is already in place, is extremely well tested, and you need to handle >> > preempt_disable()/preeempt_enable() regions of code in any case. What is >> > the real problem here? Based on your response the (PREEMPT_RCU=n, TREE_RCU=y) configuration seems to be eminently usable with this configuration. (Or maybe I'm missed the point of that discussion.) On a related note, I had started rcutorture on a (PREEMPTION=y, PREEMPT_RCU=n, TREE_RCU=y) kernel some hours ago. Nothing broken (yet!). -- ankur
