Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> writes: > 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 No worries. Given the unending context, easy enough to miss. > 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. Sounds great. Thanks. And, please keep the review comments coming. -- ankur