All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giovanni Gherdovich <ggherdovich@suse.cz>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Jon Grimm <Jon.Grimm@amd.com>,
	Nathan Fontenot <Nathan.Fontenot@amd.com>,
	Yazen Ghannam <Yazen.Ghannam@amd.com>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Suthikulpanit Suravee <Suravee.Suthikulpanit@amd.com>,
	Mel Gorman <mgorman@techsingularity.net>, Pu Wen <puwen@hygon.cn>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Michael Larabel <Michael@phoronix.com>,
	x86@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula
Date: Tue, 26 Jan 2021 10:28:30 +0100	[thread overview]
Message-ID: <1611653310.11983.66.camel@suse.cz> (raw)
In-Reply-To: <YA6XmO2nuivdpE8M@hirez.programming.kicks-ass.net>

On Mon, 2021-01-25 at 11:04 +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
> > This workload is constant in time, so instead of using the PELT sum we can
> > pretend that scale invariance is obtained with
> > 
> >     util_inv = util_raw * freq_curr / freq_max1        [formula-1]
> > 
> > where util_raw is the PELT util from v5.10 (which is to say, not invariant),
> > and util_inv is the PELT util from v5.11-rc4. freq_max1 comes from
> > commit 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
> > frequency invariance on AMD EPYC") and is (P0+max_boost)/2 = (2.25+3.4)/2 =
> > 2.825 GHz.  Then we have the schedutil formula
> > 
> >     freq_next = 1.25 * freq_max2 * util_inv            [formula-2]
> > 
> > Here v5.11-rc4 uses freq_max2 = P0 = 2.25 GHz (and this patch changes it to
> > 3.4 GHz).
> > 
> > Since all cores are busy, there is no boost available. Let's be generous and say
> > the tasks initially get P0, i.e. freq_curr = 2.25 GHz. Combining the formulas
> > above and taking util_raw = 825/1024 = 0.8, freq_next is:
> > 
> >     freq_next = 1.25 * 2.25 * 0.8 * 2.25 / 2.825 = 1.79 GHz
> 
> Right, so here's a 'problem' between schedutil and cpufreq, they don't
> use the same f_max at all times.
> 
> And this is also an inconsistency between acpi_cpufreq and intel_pstate
> (passive). IIRC the intel_pstate cpufreq drivers uses 4C/1C/P0 resp,
> while ACPI seems to stick to P0 f_max.

That's correct. A different f_max is used depending on the occasion. Let me
rephrase with:

cpufreq core asks the driver what's the f_max. What's the answer?

intel_pstate says: 1C
acpi_cpufreq says: P0

scheduler asks the freq-invariance machinery what's f_max, because it needs to
compute f_curr/f_max. What's the answer?

Intel CPUs: 4C in most cases, 1C on Atom, something else on Xeon Phi.
AMD CPUs: (P0 + 1C) / 2.


Legend:
1C = 1-core boost
4C = 4-cores boost
P0 = max non-boost P-States

> 
> Rafael; should ACPI change that behaviour rather than adding yet another
> magic variable?

  reply	other threads:[~2021-01-26 16:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 20:40 [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Giovanni Gherdovich
2021-01-22 20:40 ` [PATCH v2 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula Giovanni Gherdovich
2021-01-25 10:04   ` Peter Zijlstra
2021-01-26  9:28     ` Giovanni Gherdovich [this message]
2021-01-26 10:02       ` Peter Zijlstra
2021-02-02 18:45       ` Rafael J. Wysocki
2021-02-02 19:11         ` Rafael J. Wysocki
2021-02-03  9:56           ` Giovanni Gherdovich
2021-02-02 18:40     ` Rafael J. Wysocki
2021-01-25 10:06   ` Peter Zijlstra
2021-01-26  9:09     ` Giovanni Gherdovich
2021-01-26  9:31       ` Mel Gorman
2021-01-26 10:05         ` Peter Zijlstra
     [not found]           ` <1611933781.15858.48.camel@suse.cz>
2021-02-02 14:17             ` Giovanni Gherdovich
2021-02-02 18:21               ` Peter Zijlstra
2021-02-02 18:29                 ` Rafael J. Wysocki
2021-02-02 19:00                   ` Rafael J. Wysocki
2021-02-02 18:59   ` Rafael J. Wysocki
2021-02-02 19:26     ` Rafael J. Wysocki
2021-02-03  8:39       ` Giovanni Gherdovich
2021-02-03 13:40         ` Rafael J. Wysocki
2021-02-03  9:12     ` Giovanni Gherdovich
2021-02-03  6:04   ` Viresh Kumar
2021-01-24 22:30 ` [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Michael Larabel
2021-01-25  8:34   ` Peter Zijlstra
2021-01-26  9:01     ` Giovanni Gherdovich

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=1611653310.11983.66.camel@suse.cz \
    --to=ggherdovich@suse.cz \
    --cc=Jon.Grimm@amd.com \
    --cc=Michael@phoronix.com \
    --cc=Nathan.Fontenot@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=puwen@hygon.cn \
    --cc=rjw@rjwysocki.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.