Re: [PATCH] sched/core: Call wakeup_preempt() for queued tasks during class change

[Paul E. McKenney]

On Tue, Oct 13, 2026 at 01:06:50PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 13, 2026 at 12:55:12PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 13, 2026 at 10:57:17AM -0700, Paul E. McKenney wrote:
> > > On Tue, Oct 13, 2026 at 03:24:55PM +0000, K Prateek Nayak wrote:
> > > > Paul reported recent RCU changes exposed a lost resched where CPU idles
> > > > with a rcutorture thread waiting while being completely runnable.
> > > > 
> > > > Dumping the rq state at the time of idling with runnable tasks showed
> > > > the following:
> > > > 
> > > >   rq->next_class = &fair_sched_class
> > > >   rq->nr_running = 1
> > > >   rq->cfs.h_nr_queued = 0
> > > >   rq->rt.rt_nr_running = 1
> > > > 
> > > > Although the waiting task was an RT task, "rq->next_class" did not point
> > > > to rt_sched_class and was stuck at the lower priority fair_sched_class.
> > > 
> > > Thank you all very much!  I have started a short test.  If all goes well
> > > with the short tests, I will run an overnight test.
> > > 
> > > I will of course let you know how the individual tests go.
> > 
> > 20 minutes of 39*TREE03 (13 hours) on x86 passed!  2 hours of 9*TREE03 (18
> > hours) on arm64 in progress.  Starting five hours of 200*TREE03 on x86.
> > If that works, 12 hours of same.
> 
> And the 2 hours of 9*TREE03 on arm64 passed!  Started a 15-hour run.

And the five hours of 200*TREE03 on x86 passed!  Started a 12-hour run.

So thus far, this patch has passed bit more than 1,000 hours on x86 and
18 hours on arm64.  (Something about having access to quite a few more
x86 boxes than arm64 boxes.)

If it is still alive in the morning, Pacific Time, it will have more
than earned itself a Tested-by.  ;-)

							Thanx, Paul