From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Giovanni Gherdovich <ggherdovich@suse.cz>,
tglx@linutronix.de, mingo@redhat.com, peterz@infradead.org,
bp@suse.de, lenb@kernel.org, rjw@rjwysocki.net
Cc: x86@kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, mgorman@techsingularity.net,
matt@codeblueprint.co.uk, viresh.kumar@linaro.org,
juri.lelli@redhat.com, pjt@google.com,
vincent.guittot@linaro.org, qperret@qperret.net,
dietmar.eggemann@arm.com
Subject: Re: [PATCH 1/2] x86,sched: Add support for frequency invariance
Date: Thu, 19 Sep 2019 16:55:22 -0700 [thread overview]
Message-ID: <f5fde2bc758cc15fdb575f52c2138bb67aa514b7.camel@linux.intel.com> (raw)
In-Reply-To: <1568730426.3329.3.camel@suse.cz>
On Tue, 2019-09-17 at 16:27 +0200, Giovanni Gherdovich wrote:
> 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.
I was thinking of power efficiency use case particularly for Atom like
platforms, 1C max as you observed is more efficient.
But now sched deadline code is using arch_scale_freq_capacity(() to
calculate dl_se->runtime, where closer to deterministic value with all
cores, may be better, which will be scaled with base_freq.
Thanks,
Srinivas
next prev parent reply other threads:[~2019-09-19 23:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 2:42 [PATCH 0/2] Add support for frequency invariance for (some) x86 Giovanni Gherdovich
2019-09-09 2:42 ` [PATCH 1/2] x86,sched: Add support for frequency invariance Giovanni Gherdovich
2019-09-11 15:28 ` Doug Smythies
2019-09-13 20:58 ` Doug Smythies
2019-09-17 14:25 ` Giovanni Gherdovich
2019-09-19 14:42 ` Doug Smythies
2019-09-24 8:06 ` Mel Gorman
2019-09-24 17:52 ` Doug Smythies
2019-09-13 22:52 ` Srinivas Pandruvada
2019-09-17 14:27 ` Giovanni Gherdovich
2019-09-17 15:55 ` Vincent Guittot
2019-09-19 23:55 ` Srinivas Pandruvada [this message]
2019-09-14 10:57 ` Quentin Perret
2019-09-17 14:27 ` Giovanni Gherdovich
2019-09-17 14:39 ` Quentin Perret
2019-09-24 14:03 ` Peter Zijlstra
2019-09-24 16:00 ` Peter Zijlstra
2019-10-02 12:27 ` Giovanni Gherdovich
2019-10-02 18:45 ` Peter Zijlstra
2019-09-24 16:04 ` Peter Zijlstra
2019-10-02 12:26 ` Giovanni Gherdovich
2019-10-02 18:35 ` Peter Zijlstra
2019-09-24 16:30 ` Peter Zijlstra
2019-10-02 12:25 ` Giovanni Gherdovich
2019-10-02 18:47 ` Peter Zijlstra
2019-09-09 2:42 ` [PATCH 2/2] cpufreq: intel_pstate: Conditional frequency invariant accounting Giovanni Gherdovich
2019-09-24 16:01 ` [PATCH 0/2] Add support for frequency invariance for (some) x86 Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5fde2bc758cc15fdb575f52c2138bb67aa514b7.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=bp@suse.de \
--cc=dietmar.eggemann@arm.com \
--cc=ggherdovich@suse.cz \
--cc=juri.lelli@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=qperret@qperret.net \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).