Re: [PATCH 05/12] sched: Move sched_class::prio_changed() into the change pattern

[luca abeni]

Hi Juri,

On Wed, 14 Jan 2026 15:20:48 +0100
Juri Lelli <juri.lelli@xxxxxxxxxx> wrote:
[...]
> > > --- a/kernel/sched/deadline.c
> > > +++ b/kernel/sched/deadline.c
> > > @@ -2214,10 +2214,6 @@ enqueue_dl_entity(struct sched_dl_entity
> > >  		update_dl_entity(dl_se);
> > >  	} else if (flags & ENQUEUE_REPLENISH) {
> > >  		replenish_dl_entity(dl_se);
> > > -	} else if ((flags & ENQUEUE_RESTORE) &&
> > > -		   !is_dl_boosted(dl_se) &&
> > > -		   dl_time_before(dl_se->deadline,
> > > rq_clock(rq_of_dl_se(dl_se)))) {
> > > -		setup_new_dl_entity(dl_se);
> > >  	}
> > >  
> > >  	/*  
[...]
> > --- a/kernel/sched/syscalls.c
> > +++ b/kernel/sched/syscalls.c
> > @@ -639,7 +639,7 @@ int __sched_setscheduler(struct task_str
> >  		 * itself.
> >  		 */
> >  		newprio = rt_effective_prio(p, newprio);
> > -		if (newprio == oldprio)
> > +		if (newprio == oldprio && !dl_prio(newprio))
> >  			queue_flags &= ~DEQUEUE_MOVE;
> >  	}  
> 
> We have been using (improperly?) ENQUEUE_SAVE also to know when a new
> entity gets setscheduled to DEADLINE (or its parameters are changed)
> and it looks like this keeps that happening with DEQUEUE_MOVE.

You are right: double thinking about it, I seem to remember that the
"flags & ENQUEUE_RESTORE" check above was introduced to fix tasks
switching to SCHED_DEADLINE...

So, I agree that changing "ENQUEUE_RESTORE" to "ENQUEUE_MOVE" should be
the right thing to do


			Luca