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
