Re: [PATCH] cpufreq: intel_pstate: Implement passive mode with HWP enabled

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

On Wed, 2020-07-15 at 14:35 -0700, Francisco Jerez wrote:
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
> 
> > On Wed, Jul 15, 2020 at 2:09 AM Francisco Jerez <
> > currojerez@riseup.net> wrote:
> > > "Rafael J. Wysocki" <rjw@rjwysocki.net> writes:
> > > 
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > 

[...]

> > > > I don't think that's accurate.  I've looked at hundreds of
> > > > traces
> while
> my series [1] was in control of HWP_REQ_MAX and I've never seen an
> excursion above the maximum HWP_REQ_MAX control specified by it
> within a
> given P-state domain, even while that maximum specified was well into
> the turbo range.  So, yeah, I agree that HWP_REQ_MAX is nothing like
> a
> hard limit, particularly when multiple threads are running on the
> same
> clock domain, but the processor will still make its best effort to
> limit
> the clock frequency to the maximum of the requested maximums, even if
> it
> happens to be within the turbo range.  That doesn't make it useless.
> The exact same thing can be said about controlling HWP_REQ_MIN as
> you're
> doing now in this revision of your patch, BTW.
> 
> If you don't believe me here is the turbostat sample with maximum
> Bzy_MHz I get on the computer I'm sitting on right now while
> compiling a
> kernel on CPU0 if I set HWP_REQ_MAX to 0x1c (within the turbo range):
> 
> > Core    CPU     Avg_MHz
> > Busy%   Bzy_MHz            HWP_REQ      PkgWatt CorWatt
> > -       -       757     27.03   2800    0x0000000000000000      7.1
> > 3    4.90
> > 0       0       2794    99.77   2800    0x0000000080001c04      7.1
> > 3    4.90
> > 0       2       83      2.98    2800    0x0000000080001c04
> > 1       1       73      2.60    2800    0x0000000080001c04
> > 1       3       78      2.79    2800    0x0000000080001c04
> 
> With the default HWP_REQUEST:
> 
> > Core    CPU     Avg_MHz
> > Busy%   Bzy_MHz            HWP_REQ      PkgWatt CorWatt
> > -       -       814     27.00   3015    0x0000000000000000      8.4
> > 9    6.18
> > 0       0       2968    98.24   3021    0x0000000080001f04      8.4
> > 9    6.18
> > 0       2       84      2.81    2982    0x0000000080001f04
> > 1       1       99      3.34    2961    0x0000000080001f04
> > 1       3       105     3.60    2921    0x0000000080001f04

Correct. In HWP mode this is possible to lower limit in turbo region
conditionally. In legacy mode you can't with turbo activation ratio.

But what we don't want set max and min perf and use like desired to run
at a P-state overriding HWP or limit the range where HWP can't do any
meaningful selection.

> > Generally, I'm not quite convinced that limiting the max frequency
> > is
> > really the right choice for controlling the processor's power draw
> > on
> > the systems in question.  There are other ways to do that, which in
> > theory should be more effective.  I mentioned RAPL somewhere in
> > this
> > context and there's the GUC firmware too.
> 
> I feel like we've had that conversation before and it's somewhat
> off-topic so I'll keep it short: Yes, in theory RAPL is more
> effective
> than HWP_REQ_MAX as a mechanism to limit the absolute power
> consumption
> of the processor package, but that's not the purpose of [1], its
> purpose
> is setting a lower limit to the energy efficiency of the processor
> when
> the maximum usable CPU frequency is known (due to the existence of an
> IO
> device bottleneck) -- And if the maximum usable CPU frequency is the
> information we have at hand, controlling the maximum CPU frequency
> directly is optimal, rather than trying to find the RAPL constraint
> that
> achieves the same average frequency by trial an error.  Also, in
> theory,
> even if you had an oracle to tell you what the appropriate RAPL
> constraint is, the result would necessarily be more energy-
> inefficient
> than controlling the maximum CPU frequency directly, since you're
> giving
> the processor additional freedom to run at frequencies above the one
> you
> want to average, which is guaranteed to be more energy-inefficient
> than
> running at that fixed frequency, assuming we are in the region of
> convexity of the processor's power curve.
> 
> Anyway, if you still have some disagreement on the theoretical
> details
> you're more than welcome to bring up the matter on the other thread
> [1],
> or accept the invitation for a presentation I sent you months ago...
> ;)