From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Francisco Jerez <currojerez@riseup.net>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Linux Documentation <linux-doc@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Giovanni Gherdovich <ggherdovich@suse.cz>,
Doug Smythies <dsmythies@telus.net>
Subject: Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled
Date: Mon, 27 Jul 2020 19:23:32 +0200 [thread overview]
Message-ID: <1712943.Luj0Z5seXe@kreacher> (raw)
In-Reply-To: <87h7u0h34t.fsf@riseup.net>
On Wednesday, July 22, 2020 1:14:42 AM CEST Francisco Jerez wrote:
>
> --==-=-=
> Content-Type: multipart/mixed; boundary="=-=-="
>
> --=-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> writes:
>
> > On Mon, 2020-07-20 at 16:20 -0700, Francisco Jerez wrote:
> >> "Rafael J. Wysocki" <rafael@kernel.org> writes:
> >>=20
> >> > On Fri, Jul 17, 2020 at 2:21 AM Francisco Jerez <
> >> > currojerez@riseup.net> wrote:
> >> > > "Rafael J. Wysocki" <rafael@kernel.org> writes:
> >> > >=20
> > {...]
> >
> >> > Overall, so far, I'm seeing a claim that the CPU subsystem can be
> >> > made
> >> > use less energy and do as much work as before (which is what
> >> > improving
> >> > the energy-efficiency means in general) if the maximum frequency of
> >> > CPUs is limited in a clever way.
> >> >=20
> >> > I'm failing to see what that clever way is, though.
> >> Hopefully the clarifications above help some.
> >
> > To simplify:
> >
> > Suppose I called a function numpy.multiply() to multiply two big arrays
> > and thread is a pegged to a CPU. Let's say it is causing CPU to
> > finish the job in 10ms and it is using a P-State of 0x20. But the same
> > job could have been done in 10ms even if it was using P-state of 0x16.
> > So we are not energy efficient. To really know where is the bottle neck
> > there are numbers of perf counters, may be cache was the issue, we
> > could rather raise the uncore frequency a little. A simple APRF,MPERF
> > counters are not enough.=20
>
> Yes, that's right, APERF and MPERF aren't sufficient to identify every
> kind of possible bottleneck, some visibility of the utilization of other
> subsystems is necessary in addition -- Like e.g the instrumentation
> introduced in my series to detect a GPU bottleneck. A bottleneck
> condition in an IO device can be communicated to CPUFREQ
It generally is not sufficient to communicate it to cpufreq. It needs to be
communicated to the CPU scheduler.
> by adjusting a
> PM QoS latency request (link [2] in my previous reply) that effectively
> gives the governor permission to rearrange CPU work arbitrarily within
> the specified time frame (which should be of the order of the natural
> latency of the IO device -- e.g. at least the rendering time of a frame
> for a GPU) in order to minimize energy usage.
OK, we need to talk more about this.
> > or we characterize the workload at different P-states and set limits.
> > I think this is not you want to say for energy efficiency with your
> > changes.=20
> >
> > The way you are trying to improve "performance" is by caller (device
> > driver) to say how important my job at hand. Here device driver suppose
> > offload this calculations to some GPU and can wait up to 10 ms, you
> > want to tell CPU to be slow. But the p-state driver at a movement
> > observes that there is a chance of overshoot of latency, it will
> > immediately ask for higher P-state. So you want P-state limits based on
> > the latency requirements of the caller. Since caller has more knowledge
> > of latency requirement, this allows other devices sharing the power
> > budget to get more or less power, and improve overall energy efficiency
> > as the combined performance of system is improved.
> > Is this correct?
>
> Yes, pretty much.
OK
next prev parent reply other threads:[~2020-07-27 17:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 18:16 [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled Rafael J. Wysocki
2020-07-15 0:09 ` Francisco Jerez
2020-07-15 12:04 ` Rafael J. Wysocki
2020-07-15 21:35 ` Francisco Jerez
2020-07-16 1:14 ` Srinivas Pandruvada
2020-07-16 14:33 ` Rafael J. Wysocki
2020-07-16 14:32 ` Rafael J. Wysocki
2020-07-17 0:21 ` Francisco Jerez
2020-07-19 19:06 ` Rafael J. Wysocki
2020-07-20 23:20 ` Francisco Jerez
2020-07-21 16:25 ` Srinivas Pandruvada
2020-07-21 23:14 ` Francisco Jerez
2020-07-27 17:23 ` Rafael J. Wysocki [this message]
2020-07-27 17:15 ` Rafael J. Wysocki
2020-07-28 2:32 ` Francisco Jerez
2020-07-28 18:27 ` Rafael J. Wysocki
2020-07-29 5:46 ` Francisco Jerez
2020-07-29 17:52 ` Rafael J. Wysocki
2020-07-30 0:49 ` Francisco Jerez
2020-07-31 17:52 ` Rafael J. Wysocki
2020-07-31 22:43 ` Francisco Jerez
2020-07-28 15:41 ` Rafael J. Wysocki
2020-07-15 20:39 ` Doug Smythies
2020-07-16 12:07 ` Rafael J. Wysocki
2020-07-17 13:37 ` Doug Smythies
2020-07-19 11:42 ` Rafael J. Wysocki
2020-08-02 15:17 ` Doug Smythies
2020-08-03 17:08 ` Rafael J. Wysocki
2020-08-06 5:54 ` Doug Smythies
2020-08-06 11:39 ` Rafael J. Wysocki
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=1712943.Luj0Z5seXe@kreacher \
--to=rjw@rjwysocki.net \
--cc=currojerez@riseup.net \
--cc=dsmythies@telus.net \
--cc=ggherdovich@suse.cz \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/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).