From: "Rafael J. Wysocki" <email@example.com>
To: Srinivas Pandruvada <firstname.lastname@example.org>
Cc: "Rafael J. Wysocki" <email@example.com>,
Giovanni Gherdovich <firstname.lastname@example.org>,
Thomas Gleixner <email@example.com>,
Ingo Molnar <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Borislav Petkov <firstname.lastname@example.org>, Len Brown <email@example.com>,
"the arch/x86 maintainers" <firstname.lastname@example.org>,
Linux PM <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Mel Gorman <email@example.com>,
Matt Fleming <firstname.lastname@example.org>,
Viresh Kumar <email@example.com>,
Juri Lelli <firstname.lastname@example.org>, Paul Turner <email@example.com>,
Vincent Guittot <firstname.lastname@example.org>,
Quentin Perret <email@example.com>,
Dietmar Eggemann <firstname.lastname@example.org>,
Doug Smythies <email@example.com>
Subject: Re: [PATCH v2 2/2] cpufreq: intel_pstate: Conditional frequency invariant accounting
Date: Fri, 4 Oct 2019 10:08:52 +0200 [thread overview]
Message-ID: <CAJZ5v0hzrGQ8Tt2HO5DAAJdsEbEZPAnnvYG6LkdeMJgonVv0yA@mail.gmail.com> (raw)
On Fri, Oct 4, 2019 at 5:31 AM Srinivas Pandruvada
> On Thu, 2019-10-03 at 20:05 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, October 2, 2019 2:29:26 PM CEST Giovanni Gherdovich
> > wrote:
> > > From: Srinivas Pandruvada <firstname.lastname@example.org>
> > >
> > > intel_pstate has two operating modes: active and passive. In
> > > "active"
> > > mode, the in-built scaling governor is used and in "passive" mode,
> > > the driver can be used with any governor like "schedutil". In
> > > "active"
> > > mode the utilization values from schedutil is not used and there is
> > > a requirement from high performance computing use cases, not to
> > > readas well
> > > any APERF/MPERF MSRs.
> > Well, this isn't quite convincing.
> > In particular, I don't see why the "don't read APERF/MPERF MSRs"
> > argument
> > applies *only* to intel_pstate in the "active" mode. What about
> > intel_pstate
> > in the "passive" mode combined with the "performance" governor? Or
> > any other
> > governor different from "schedutil" for that matter?
> > And what about acpi_cpufreq combined with any governor different from
> > "schedutil"?
> > Scale invariance is not really needed in all of those cases right now
> > AFAICS,
> > or is it?
> Correct. This is just part of the patch to disable in active mode
> (particularly in HWP and performance mode).
> But this patch is 2 years old. The folks who wanted this, disable
> intel-pstate and use userspace governor with acpi-cpufreq. So may be
> better to address those cases too.
Well, that's my point. :-)
It looks like the scale invariance is only needed when the schedutil
governor is used, regardless of the driver, and it may lead to
performance degradation in the other cases, at least in principle (I
wonder, though, if any hard data supporting that claim are available).
That can be addressed in two ways IMO, either by reducing the possible
negative impact of the scale invariance code (eg. by running it less
frequently), so that it can be always enabled (as long as it is
supported by the processor), or by avoiding to run it in all cases
when it is not needed (but that basically would require the governor
->init and ->exit to enable and disable the scale invariance,
> > So is the real concern that intel_pstate in the "active" mode reads
> > the MPERF
> > and APERF MSRs by itself and that kind of duplicates what the scale
> > invariance
> > code does and is redundant etc?
> It is redundant in non-HWP mode. In HWP and performance (active mode)
> we don't use atleast at this time.
next prev parent reply other threads:[~2019-10-04 8:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 12:29 [PATCH v2 0/2] Add support for frequency invariance for (some) x86 Giovanni Gherdovich
2019-10-02 12:29 ` [PATCH v2 1/2] x86,sched: Add support for frequency invariance Giovanni Gherdovich
2019-10-02 15:23 ` kbuild test robot
2019-10-02 15:49 ` Giovanni Gherdovich
2019-10-02 16:43 ` kbuild test robot
2019-10-02 18:27 ` Peter Zijlstra
2019-10-03 10:27 ` Rafael J. Wysocki
2019-10-03 12:15 ` Peter Zijlstra
2019-10-03 17:36 ` Srinivas Pandruvada
2019-10-03 17:53 ` Rafael J. Wysocki
2019-10-04 11:48 ` Peter Zijlstra
2019-10-08 7:48 ` Giovanni Gherdovich
2019-10-08 9:32 ` Rafael J. Wysocki
2019-10-02 12:29 ` [PATCH v2 2/2] cpufreq: intel_pstate: Conditional frequency invariant accounting Giovanni Gherdovich
2019-10-03 18:05 ` Rafael J. Wysocki
2019-10-04 3:31 ` Srinivas Pandruvada
2019-10-04 8:08 ` Rafael J. Wysocki [this message]
2019-10-04 8:29 ` Giovanni Gherdovich
2019-10-04 8:28 ` Vincent Guittot
2019-10-04 8:33 ` Rafael J. Wysocki
2019-10-04 8:29 ` Rafael J. Wysocki
2019-10-04 8:57 ` Giovanni Gherdovich
2019-10-04 9:17 ` Rafael J. Wysocki
2019-10-04 15:17 ` Srinivas Pandruvada
2019-10-07 8:33 ` Giovanni Gherdovich
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).