Re: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT

[Ankur Arora]

Paul E. McKenney <paulmck@xxxxxxxxxx> writes:

> On Tue, Dec 05, 2023 at 10:01:14AM -0500, Steven Rostedt wrote:
>> On Mon, 4 Dec 2023 17:01:21 -0800
>> "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
>>
>> > On Tue, Nov 28, 2023 at 11:53:19AM +0100, Thomas Gleixner wrote:
>> > > Paul!
>> > >
>> > > On Tue, Nov 21 2023 at 07:19, Paul E. McKenney wrote:
>> > > > On Tue, Nov 21, 2023 at 10:00:59AM -0500, Steven Rostedt wrote:
...
>> > >   3) Looking at the initial problem Ankur was trying to solve there is
>> > >      absolutely no acceptable solution to solve that unless you think
>> > >      that the semantically invers 'allow_preempt()/disallow_preempt()'
>> > >      is anywhere near acceptable.
>> >
>> > I am not arguing for allow_preempt()/disallow_preempt(), so for that
>> > argument, you need to find someone else to argue with.  ;-)
>>
>> Anyway, there's still a long path before cond_resched() can be removed. It
>> was a mistake by Ankur to add those removals this early (and he has
>> acknowledged that mistake).
>
> OK, that I can live with.  But that seems to be a bit different of a
> take than that of some earlier emails in this thread.  ;-)

Heh I think it's just that this thread goes to (far) too many places :).

As Steven says, the initial series touching everything all together
was a mistake. V1 adds the new preemption model alongside the existing
ones locally defines cond_resched() as nop.

That'll allow us to experiment and figure out where there are latency
gaps.

Ankur