Paul E. McKenney <paulmck@xxxxxxxxxx> writes: > On Tue, Dec 05, 2023 at 12:18:26PM -0800, Ankur Arora wrote: >> >> 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. > > Sounds very good! > > Again, I am very supportive of the overall direction. Devils and details > and all that. ;-) Agreed. And thanks! -- ankur
