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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfTPtAyiKtbXb6s-GV3g=G0e7ipK6vZJFoOKno5tmntyJsCOQ@mail.gmail.com>
Date:   Tue, 19 Jan 2021 18:06:46 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Qais Yousef <qais.yousef@....com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is pinned

On Tue, 19 Jan 2021 at 17:55, Valentin Schneider
<valentin.schneider@....com> wrote:
>
> On 19/01/21 15:19, Vincent Guittot wrote:
> > On Tue, 19 Jan 2021 at 14:54, Valentin Schneider
> > <valentin.schneider@....com> 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
> >> >>