On Mon, 20 Nov 2023 21:04:28 -0800 "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > How about like this, where "Y" means allowed and "N" means not allowed: > > Non-Preemptible RCU Preemptible RCU > > NONE: Y Y > > VOLUNTARY: Y Y > > PREEMPT: N Y > > PREEMPT_RT: N Y > > > We need preemptible RCU for NONE and VOLUNTARY, as you say, > to allow CONFIG_PREEMPT_DYNAMIC to continue to work. (OK, OK, > CONFIG_PREEMPT_DYNAMIC is no longer, but appears to be unconditional.) > But again, I don't see why anyone would want (much less need) > non-preemptible RCU in the PREEMPT and PREEMPT_RT cases. And if it is > neither wanted nor needed, there is no point in enabling it, much less > testing it. > > Or am I missing a use case in there somewhere? As Ankur replied, this is just an RFC, not the main goal. I'm talking about the end product which will get rid of the PREEMPT_NONE, PREEMPT_VOLUNTARY and PREEMPT conifgs, and there will *only* be the PREEMPT_DYNAMIC and PREEMPT_RT. And yes, this is going to be a slow and long processes, to find and fix all regressions. I too am concerned about the latency that this may add. I'm thinking we could have NEED_RESCHED_LAZY preempt when there is no mutex or other semi critical section held (like migrate_disable()). Right now, the use of cond_resched() is basically a whack-a-mole game where we need to whack all the mole loops with the cond_resched() hammer. As Thomas said, this is backwards. It makes more sense to just not preempt in areas that can cause pain (like holding a mutex or in an RCU critical section), but still have the general kernel be fully preemptable. -- Steve
