linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giovanni Gherdovich <ggherdovich@suse.cz>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	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: Tue, 17 Sep 2019 16:27:06 +0200	[thread overview]
Message-ID: <1568730426.3329.3.camel@suse.cz> (raw)
In-Reply-To: <4226d5f460604a8130f8079b74ef3fb1d60009d7.camel@linux.intel.com>

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

  reply	other threads:[~2019-09-17 14:21 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 [this message]
2019-09-17 15:55       ` Vincent Guittot
2019-09-19 23:55       ` Srinivas Pandruvada
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=1568730426.3329.3.camel@suse.cz \
    --to=ggherdovich@suse.cz \
    --cc=bp@suse.de \
    --cc=dietmar.eggemann@arm.com \
    --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=srinivas.pandruvada@linux.intel.com \
    --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).