Steven Rostedt <rostedt@xxxxxxxxxxx> writes: > On Wed, 8 Nov 2023 13:16:17 +0100 > Eric Dumazet <edumazet@xxxxxxxxxx> wrote: > >> > Most of the uses here are in set-1 (some right after we give up a >> > lock or enable bottom-halves, causing an explicit preemption check.) >> > >> > We can remove all of them. >> >> A patch series of 86 is not reasonable. /me nods. > Agreed. The removal of cond_resched() wasn't needed for the RFC, as there's > really no comments needed once we make cond_resched obsolete. > > I think Ankur just wanted to send all the work for the RFC to let people > know what he has done. I chalk that up as a Noobie mistake. > > Ankur, next time you may want to break things up to get RFCs for each step > before going to the next one. Yeah agreed. It would have made sense to break this up into changes touching the scheduler code first, get agreement. Rinse. Repeat. > Currently, it looks like the first thing to do is to start with Thomas's > patch, and get the kinks out of NEED_RESCHED_LAZY, as Thomas suggested. > > Perhaps work on separating PREEMPT_RCU from PREEMPT. Agree to both of those. > Then you may need to work on handling the #ifndef PREEMPTION parts of the > kernel. In other words express !PREEMPTION scheduler models/things that depend on cond_resched() etc, into Thomas' model? > And so on. Each being a separate patch series that will affect the way the > rest of the changes will be done. Ack that. > I want this change too, so I'm willing to help you out on this. If you > didn't start it, I would have ;-) Thanks and I really appreciate that. -- ankur