linux-kernel - Re: [PATCH v8 5/9] sched/fair: Take into account latency priority at wakeup

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: <CAKfTPtAJrai_KYUcT=deSjxZ835Ou_RyxdNpZc0Gnb3_NA2iKA@mail.gmail.com>
Date:   Tue, 15 Nov 2022 16:40:28 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Patrick Bellasi <patrick.bellasi@...bug.net>
Cc:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org, parth@...ux.ibm.com,
        qyousef@...alina.io, chris.hyser@...cle.com,
        David.Laight@...lab.com, pjt@...gle.com, pavel@....cz,
        tj@...nel.org, qperret@...gle.com, tim.c.chen@...ux.intel.com,
        joshdon@...gle.com, timj@....org, kprateek.nayak@....com,
        yu.c.chen@...el.com, youssefesmat@...omium.org,
        joel@...lfernandes.org
Subject: Re: [PATCH v8 5/9] sched/fair: Take into account latency priority at wakeup

On Mon, 14 Nov 2022 at 17:20, Patrick Bellasi
<patrick.bellasi@...bug.net> wrote:
>
> Hi Vincent,
>
> On 10-Nov 18:50, Vincent Guittot wrote:
>
> [...]
>
> > diff --git a/init/init_task.c b/init/init_task.c
> > index 7dd71dd2d261..b8ddf403bc62 100644
> > --- a/init/init_task.c
> > +++ b/init/init_task.c
> > @@ -78,7 +78,7 @@ struct task_struct init_task
> >       .prio           = MAX_PRIO - 20,
> >       .static_prio    = MAX_PRIO - 20,
> >       .normal_prio    = MAX_PRIO - 20,
> > -     .latency_nice   = DEFAULT_LATENCY_NICE,
> > +     .latency_prio   = NICE_WIDTH - 20,
>                     ^^^^^^^^^^
>
> For robustness/consistency, shoudln't this be LATENCY_NICE_WIDTH?

yes, good catch

>
> [...]
>
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index b2accc9da4fe..caf54e54a74f 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1284,6 +1284,16 @@ static void set_load_weight(struct task_struct *p, bool update_load)
> >       }
> >  }
> >
> > +static void set_latency_offset(struct task_struct *p)
> > +{
> > +     long weight = sched_latency_to_weight[p->latency_prio];
> > +     s64 offset;
> > +
> > +     offset = weight * get_sched_latency(false);
>                       ^^^^^^^^^^^^^^^^^^^^^^^^
> As per my comment in patch 1, we almost always (but one time) call this with
> "false" and that's not returning the sysctl_sched_latency but a possibly
> discounted value in case of feat(GENTLE_FAIR_SLEEPERS).
>
> Just to avoid confusion (this could be not the sched_latency) and to better
> document the code, what about using a accessor define something like e.g.
>
>    #define max_wakeup_latency get_wakeup_latency(false)
>
> ?
>
> [...]
>
> Best,
> Patrick
>
> --
> #include <best/regards.h>
>
> Patrick Bellasi