Re: [PATCH] sched/eas: Don't update misfit status if the task is pinned

[Vincent Guittot]

On Tue, 19 Jan 2021 at 17:55, Valentin Schneider
<valentin.schneider@xxxxxxx> wrote:
>
> On 19/01/21 15:19, Vincent Guittot wrote:
> > On Tue, 19 Jan 2021 at 14:54, Valentin Schneider
> > <valentin.schneider@xxxxxxx> wrote:
> >> On 19/01/21 14:34, Vincent Guittot wrote:
> >> >> -       if (!p) {
> >> >> +       if (!p || p->nr_cpus_allowed == 1) {
> >> >
> >> > Side question: What happens if there is 2 misfit tasks and the current
> >> > one is pinned but not the other waiting one
> >> >
> >>
> >> update_misfit_status() is called either on the current task (at tick) or
> >> on the task picked by pick_next_task_fair() - i.e. CFS current or
> >> about-to-be-current.
> >>
> >> So if you have 2 CPU hogs enqueued on a single LITTLE, and one of them
> >> is pinned, the other one will be moved away either via regular load
> >
> > This doesn't seem reliable because it uses load or nr_running
> >
>
> Right
>
> >> balance, or via misfit balance sometime after it's picked as the next
> >> task to run.
> >>
> >> Admittedly that second case suffers from unfortunate timing mostly
> >> related to the load balance interval. There was an old patch in the
> >> Android stack that would reduce the balance interval upon detecting a
> >
> > Shouldn't we keep track of enqueue misfit tasks instead ?
> >
>
> That might help. This being CFS however, the maintenance of it might
> prove prohibitive. I faintly recall having concerns about expanding the
> misfit logic to non-current tasks, but nothing comes to mind right
> now...
>
> Historically (before PELT time scaling) I think it wasn't possible to
> have a steady state with more than one misfit task on a rq, as two
> similar CPU hogs would end up with a utilization value of at most half
> the CPU's capacity. If those were at e.g. opposite ends of the NICE
> spectrum, if one would be flagged as misfit then the other wouldn't
> (can't have two slices greater than 80%!)

I remember this

>
> I *think* that's still true with timescaling, but then we did add the
> uclamp stuff to make tasks look bigger than they are...

Yeah, uclamp makes it possible now

>
> >> misfit task to "accelerate" its upmigration; this might need to be
> >> revisited...
> >>
> >> >>                 rq->misfit_task_load = 0;
> >> >>                 return;
> >> >>         }
> >> >> --
> >> >> 2.25.1
> >> >>