On 08/08/19 12:31, Peter Zijlstra wrote: > On Thu, Aug 08, 2019 at 10:46:52AM +0200, Juri Lelli wrote: > > On 08/08/19 10:11, Dietmar Eggemann wrote: > > > > What about the fast path in pick_next_task()? > > > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > > index bffe849b5a42..f1ea6ae16052 100644 > > > --- a/kernel/sched/core.c > > > +++ b/kernel/sched/core.c > > > @@ -3742,6 +3742,9 @@ pick_next_task(struct rq *rq, struct task_struct > > > *prev, struct rq_flags *rf) > > > if (unlikely(!p)) > > > p = idle_sched_class.pick_next_task(rq, prev, rf); > > > > > > + if (p->sched_class == &fair_sched_class && p->server) > > > + p->server = NULL; > > > + > > > > Hummm, but then who sets it back to the correct server. AFAIU > > update_curr() needs a ->server to do the correct DL accounting? > > The above looks ok. > > The pick_next_task_dl() when it selects a server will set ->server.
OK. Yesterday's IRC conversation resolved my perplexity about this point. I tried to summarize what I've got in the comment below (which we might want to add on top of Dietmar's fix). --->8--- /* * Since we are executing the fast path it means that the DL * server was throttled and we'll now be scheduled w/o it. So, * reset p's pointer to it (accounting won't be performed, as * it wouldn't make sense while server is thottled). */
