[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260114162549.613551f2@nowhere>
Date: Wed, 14 Jan 2026 16:25:49 +0100
From: luca abeni <luca.abeni@...tannapisa.it>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>, K Prateek Nayak
<kprateek.nayak@....com>, Pierre Gondois <pierre.gondois@....com>,
tj@...nel.org, linux-kernel@...r.kernel.org, mingo@...nel.org,
vincent.guittot@...aro.org, dietmar.eggemann@....com, rostedt@...dmis.org,
bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
longman@...hat.com, hannes@...xchg.org, mkoutny@...e.com,
void@...ifault.com, arighi@...dia.com, changwoo@...lia.com,
cgroups@...r.kernel.org, sched-ext@...ts.linux.dev, liuwenfang@...or.com,
tglx@...utronix.de, Christian Loehle <christian.loehle@....com>
Subject: Re: [PATCH 05/12] sched: Move sched_class::prio_changed() into the
change pattern
Hi Juri,
On Wed, 14 Jan 2026 15:20:48 +0100
Juri Lelli <juri.lelli@...hat.com> 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
Powered by blists - more mailing lists