On 3/11/2024 11:16 PM, Ankur Arora wrote: > > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> writes: > >> Hi, Thomas, >> Thanks for your reply! I replied below. >> >> On 3/11/2024 3:12 PM, Thomas Gleixner wrote: >>> On Mon, Mar 11 2024 at 11:25, Joel Fernandes wrote: > > [ ... ] > >>> What's wrong with the combination of PREEMPT_AUTO=y and PREEMPT_RCU=n? >>> Paul and me agreed long ago that this needs to be supported. >> >> There's nothing wrong with it. Its just a bit quirky (again just a point of >> view), that for a configuration that causes preemption (similar to >> CONFIG_PREEMPT=y), that PREEMPT_RCU can be disabled. After all, again with >> CONFIG_PREEMPT=y, PREEMPT_RCU cannot be currently disabled. > > I think the argument was that PREEMPT_RCU=y is suboptimal for certain > workloads, and those configurations might prefer the stronger > forward-progress guarantees that PREEMPT_RCU=n provides. > > See this: > https://lore.kernel.org/lkml/73ecce1c-d321-4579-b892-13b1e0a0620a@paulmck-laptop/T/#m6aab5a6fd5f1fd4c3dc9282ce564e64f2fa6cdc3 > > and the surrounding thread. Thanks for the link. Sorry for any noise due to being late to the party. Based on the discussions, I concur with everyone on the goal of getting rid of CONFIG_PREEMPT_DYNAMIC and the various cond_resched()/might_sleep() things. I'll also go look harder at what else we need to get CONFIG_PREEMPT_RCU=y/n working with CONFIG_PREEMPT_AUTO=y. thanks, - Joel
