Re: [RFC][PATCH 5/5] sched: Add ttwu_queue support for delayed tasks

[Peter Zijlstra]

On Fri, Jun 13, 2025 at 09:34:22AM +0200, Dietmar Eggemann wrote:
> On 20/05/2025 11:45, Peter Zijlstra wrote:
> 
> [...]
> 
> > @@ -3830,12 +3859,41 @@ void sched_ttwu_pending(void *arg)
> >  	update_rq_clock(rq);
> >  
> >  	llist_for_each_entry_safe(p, t, llist, wake_entry.llist) {
> > +		struct rq *p_rq = task_rq(p);
> > +		int ret;
> > +
> > +		/*
> > +		 * This is the ttwu_runnable() case. Notably it is possible for
> > +		 * on-rq entities to get migrated -- even sched_delayed ones.
> > +		 */
> > +		if (unlikely(p_rq != rq)) {
> > +			rq_unlock(rq, &rf);
> > +			p_rq = __task_rq_lock(p, &rf);
> 
> I always get this fairly early with TTWU_QUEUE_DELAYED enabled, related
> to p->pi_lock not held in wakeup from interrupt.
> 
> [   36.175285] WARNING: CPU: 0 PID: 162 at kernel/sched/core.c:679 __task_rq_lock+0xf8/0x128

Thanks, let me go have a look.

> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -2313,6 +2313,7 @@ static inline int task_on_rq_migrating(s
> >  #define WF_RQ_SELECTED		0x80 /* ->select_task_rq() was called */
> >  
> >  #define WF_ON_CPU		0x0100
> 
> Looks like there is no specific handling for WF_ON_CPU yet?

Oh, indeed. That didn't survive the tinkering and then I forgot to clean
it up here. Let me go find a broom and sweep these few bits under the
carpet then :-)