linux-kernel - Re: [PATCH 1/2] x86,sched: Add support for frequency invariance

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: <1568730426.3329.3.camel@suse.cz>
Date:   Tue, 17 Sep 2019 16:27:06 +0200
From:   Giovanni Gherdovich <ggherdovich@...e.cz>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        tglx@...utronix.de, mingo@...hat.com, peterz@...radead.org,
        bp@...e.de, lenb@...nel.org, rjw@...ysocki.net
Cc:     x86@...nel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, mgorman@...hsingularity.net,
        matt@...eblueprint.co.uk, viresh.kumar@...aro.org,
        juri.lelli@...hat.com, pjt@...gle.com, vincent.guittot@...aro.org,
        qperret@...rret.net, dietmar.eggemann@....com
Subject: Re: [PATCH 1/2] x86,sched: Add support for frequency invariance

Hello Srinivas,

On Fri, 2019-09-13 at 15:52 -0700, Srinivas Pandruvada wrote:
> On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote:
> 
> ...
> 
> > +
> > +/*
> > + * APERF/MPERF frequency ratio computation.
> > + *
> > + * The scheduler wants to do frequency invariant accounting and
> > needs a <1
> > + * ratio to account for the 'current' frequency, corresponding to
> > + * freq_curr / freq_max.
> 
> I thought this is no longer the restriction and Vincent did some work
> to remove this restriction. 

If you're referring to the patch

  23127296889f "sched/fair: Update scale invariance of PELT"

merged in v5.2, I'm familiar with that and from my understanding you still
want a <1 scaling factor. This is my recalling of the patch:

Vincent was studying some synthetic traces and realized that util_avg reported
by PELT didn't quite match the result you'd get computing the formula with pen
and paper (theoretical value). To address this he changed where the scaling
factor is applied in the PELT formula.

At some point when accumulating the PELT sums, you'll have to measure the time
'delta' since you last updated PELT. What we have after Vincent's change is
that this time length 'delta' gets itself scaled by the freq_curr/freq_max
ratio:

    delta = time since last PELT update
    delta *= freq_percent

In this way time goes at "wall clock speed" only when you're running at max
capacitiy, and goes "slower" (from the PELT point of view) if we're running at
a lower frequency. I don't think Vincent had in mind a faster-than-wall-clock
PELT time (which you'd get w/ freq_percent>1).

Speaking of which, Srinivas, do you have any opinion and/or requirement about
this? I confusely remember Peter Zijlstra saying (more than a year ago, now)
that you would like an unclipped freq_curr/freq_max ratio, and may not be
happy with this patch clipping it to 1 when freq_curr > 4_cores_turbo. If
that's the case, could you elaborate on this?
Ignore that if it doesn't make sense, I may be mis-remembering.

Thanks,
Giovanni