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. ;-) Thanx, Paul
