From: "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
To: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"currojerez@riseup.net" <currojerez@riseup.net>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Subject: Re: [Intel-gfx] [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts.
Date: Mon, 23 Mar 2020 20:13:06 +0000 [thread overview]
Message-ID: <c43ab3612650e359c04693b239bfd7ebef439ad3.camel@intel.com> (raw)
In-Reply-To: <87blot76rx.fsf@riseup.net>
On Wed, 2020-03-18 at 13:22 -0700, Francisco Jerez wrote:
> "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> writes:
>
> > On Wed, 2020-03-18 at 12:51 -0700, Francisco Jerez wrote:
> > > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> writes:
> > >
> > > > On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
> > > > > This implements a simple variably low-pass-filtering governor
> > > > > in
> > > > > control of the HWP MIN/MAX PERF range based on the previously
> > > > > introduced get_vlp_target_range(). See "cpufreq:
> > > > > intel_pstate:
> > > > > Implement VLP controller target P-state range estimation."
> > > > > for
> > > > > the
> > > > > rationale.
> > > >
> > > > I just gave a try on a pretty idle system with just systemd
> > > > processes
> > > > and usual background tasks with nomodset.
> > > >
> > > > I see that there HWP min is getting changed between 4-8. Why
> > > > are
> > > > changing HWP dynamic range even on an idle system running no
> > > > where
> > > > close to TDP?
> > > >
> > >
> > > The HWP request range is clamped to the frequency range specified
> > > by
> > > the
> > > CPUFREQ policy and to the cpu->pstate.min_pstate bound.
> > >
> > > If you see the HWP minimum fluctuating above that it's likely a
> > > sign
> > > of
> > > your system not being completely idle -- If that's the case it's
> > > likely
> > > to go away after you do:
> > >
> > > echo 0 > /sys/kernel/debug/pstate_snb/vlp_realtime_gain_pml
> > >
> > The objective which I though was to improve performance of GPU
> > workloads limited by TDP because of P-states ramping up and
> > resulting
> > in less power to GPU to complete a task.
> >
> > HWP takes decision not on just load on a CPU but several other
> > factors
> > like total SoC power and scalability. We don't want to disturb HWP
> > algorithms when there is no TDP limitations. If writing 0, causes
> > this
> > behavior then that should be the default.
> >
>
> The heuristic disabled by that debugfs file is there to avoid
> regressions in latency-sensitive workloads as you can probably get
> from
> the ecomments. However ISTR those regressions were specific to non-
> HWP
> systems, so I wouldn't mind disabling it for the moment (or punting
> it
> to the non-HWP series if you like)j. But first I need to verify that
> there are no performance regressions on HWP systems after changing
> that.
> Can you confirm that the debugfs write above prevents the behavior
> you'd
> like to avoid?
It does prevent. I monitored for 10 min and didn't see any hwp_req
update.
Thanks,
Srinivas
>
> > Thanks,
> > Srinivas
> >
> >
> >
> >
> >
> > > > Thanks,
> > > > Srinivas
> > > >
> > > >
> > > > > Signed-off-by: Francisco Jerez <currojerez@riseup.net>
> > > > > ---
> > > > > drivers/cpufreq/intel_pstate.c | 79
> > > > > +++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 77 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > index cecadfec8bc1..a01eed40d897 100644
> > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > @@ -1905,6 +1905,20 @@ static void
> > > > > intel_pstate_reset_vlp(struct
> > > > > cpudata *cpu)
> > > > > vlp->gain = max(1, div_fp(1000,
> > > > > vlp_params.setpoint_0_pml));
> > > > > vlp->target.p_base = 0;
> > > > > vlp->stats.last_response_frequency_hz =
> > > > > vlp_params.avg_hz;
> > > > > +
> > > > > + if (hwp_active) {
> > > > > + const uint32_t p0 = max(cpu->pstate.min_pstate,
> > > > > + cpu->min_perf_ratio);
> > > > > + const uint32_t p1 = max_t(uint32_t, p0, cpu-
> > > > > > max_perf_ratio);
> > > > > + const uint64_t hwp_req = (READ_ONCE(cpu-
> > > > > > hwp_req_cached) &
> > > > > + ~(HWP_MAX_PERF(~0L) |
> > > > > + HWP_MIN_PERF(~0L) |
> > > > > + HWP_DESIRED_PERF(~0
> > > > > L))) |
> > > > > + HWP_MIN_PERF(p0) |
> > > > > HWP_MAX_PERF(p1);
> > > > > +
> > > > > + wrmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST,
> > > > > hwp_req);
> > > > > + cpu->hwp_req_cached = hwp_req;
> > > > > + }
> > > > > }
> > > > >
> > > > > /**
> > > > > @@ -2222,6 +2236,46 @@ static void
> > > > > intel_pstate_adjust_pstate(struct
> > > > > cpudata *cpu)
> > > > > fp_toint(cpu->iowait_boost * 100));
> > > > > }
> > > > >
> > > > > +static void intel_pstate_adjust_pstate_range(struct cpudata
> > > > > *cpu,
> > > > > + const unsigned int
> > > > > range[])
> > > > > +{
> > > > > + const int from = cpu->hwp_req_cached;
> > > > > + unsigned int p0, p1, p_min, p_max;
> > > > > + struct sample *sample;
> > > > > + uint64_t hwp_req;
> > > > > +
> > > > > + update_turbo_state();
> > > > > +
> > > > > + p0 = max(cpu->pstate.min_pstate, cpu->min_perf_ratio);
> > > > > + p1 = max_t(unsigned int, p0, cpu->max_perf_ratio);
> > > > > + p_min = clamp_t(unsigned int, range[0], p0, p1);
> > > > > + p_max = clamp_t(unsigned int, range[1], p0, p1);
> > > > > +
> > > > > + trace_cpu_frequency(p_max * cpu->pstate.scaling, cpu-
> > > > > >cpu);
> > > > > +
> > > > > + hwp_req = (READ_ONCE(cpu->hwp_req_cached) &
> > > > > + ~(HWP_MAX_PERF(~0L) | HWP_MIN_PERF(~0L) |
> > > > > + HWP_DESIRED_PERF(~0L))) |
> > > > > + HWP_MIN_PERF(vlp_params.debug & 2 ? p0 :
> > > > > p_min) |
> > > > > + HWP_MAX_PERF(vlp_params.debug & 4 ? p1 :
> > > > > p_max);
> > > > > +
> > > > > + if (hwp_req != cpu->hwp_req_cached) {
> > > > > + wrmsrl(MSR_HWP_REQUEST, hwp_req);
> > > > > + cpu->hwp_req_cached = hwp_req;
> > > > > + }
> > > > > +
> > > > > + sample = &cpu->sample;
> > > > > + trace_pstate_sample(mul_ext_fp(100, sample-
> > > > > >core_avg_perf),
> > > > > + fp_toint(sample->busy_scaled),
> > > > > + from,
> > > > > + hwp_req,
> > > > > + sample->mperf,
> > > > > + sample->aperf,
> > > > > + sample->tsc,
> > > > > + get_avg_frequency(cpu),
> > > > > + fp_toint(cpu->iowait_boost * 100));
> > > > > +}
> > > > > +
> > > > > static void intel_pstate_update_util(struct update_util_data
> > > > > *data,
> > > > > u64 time,
> > > > > unsigned int flags)
> > > > > {
> > > > > @@ -2260,6 +2314,22 @@ static void
> > > > > intel_pstate_update_util(struct
> > > > > update_util_data *data, u64 time,
> > > > > intel_pstate_adjust_pstate(cpu);
> > > > > }
> > > > >
> > > > > +/**
> > > > > + * Implementation of the cpufreq update_util hook based on
> > > > > the
> > > > > VLP
> > > > > + * controller (see get_vlp_target_range()).
> > > > > + */
> > > > > +static void intel_pstate_update_util_hwp_vlp(struct
> > > > > update_util_data
> > > > > *data,
> > > > > + u64 time, unsigned
> > > > > int
> > > > > flags)
> > > > > +{
> > > > > + struct cpudata *cpu = container_of(data, struct
> > > > > cpudata,
> > > > > update_util);
> > > > > +
> > > > > + if (update_vlp_sample(cpu, time, flags)) {
> > > > > + const struct vlp_target_range *target =
> > > > > + get_vlp_target_range(cpu);
> > > > > + intel_pstate_adjust_pstate_range(cpu, target-
> > > > > >value);
> > > > > + }
> > > > > +}
> > > > > +
> > > > > static struct pstate_funcs core_funcs = {
> > > > > .get_max = core_get_max_pstate,
> > > > > .get_max_physical = core_get_max_pstate_physical,
> > > > > @@ -2389,6 +2459,9 @@ static int
> > > > > intel_pstate_init_cpu(unsigned
> > > > > int
> > > > > cpunum)
> > > > >
> > > > > intel_pstate_get_cpu_pstates(cpu);
> > > > >
> > > > > + if (pstate_funcs.update_util ==
> > > > > intel_pstate_update_util_hwp_vlp)
> > > > > + intel_pstate_reset_vlp(cpu);
> > > > > +
> > > > > pr_debug("controlling: cpu %d\n", cpunum);
> > > > >
> > > > > return 0;
> > > > > @@ -2398,7 +2471,8 @@ static void
> > > > > intel_pstate_set_update_util_hook(unsigned int cpu_num)
> > > > > {
> > > > > struct cpudata *cpu = all_cpu_data[cpu_num];
> > > > >
> > > > > - if (hwp_active && !hwp_boost)
> > > > > + if (hwp_active && !hwp_boost &&
> > > > > + pstate_funcs.update_util !=
> > > > > intel_pstate_update_util_hwp_vlp)
> > > > > return;
> > > > >
> > > > > if (cpu->update_util_set)
> > > > > @@ -2526,7 +2600,8 @@ static int
> > > > > intel_pstate_set_policy(struct
> > > > > cpufreq_policy *policy)
> > > > > * was turned off, in that case we need to
> > > > > clear the
> > > > > * update util hook.
> > > > > */
> > > > > - if (!hwp_boost)
> > > > > + if (!hwp_boost && pstate_funcs.update_util !=
> > > > > + intel_pstate_update_util_hwp_
> > > > > vlp)
> > > > > intel_pstate_clear_update_util_hook(pol
> > > > > icy-
> > > > > > cpu);
> > > > > intel_pstate_hwp_set(policy->cpu);
> > > > > }
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-23 20:13 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 21:41 [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2) Francisco Jerez
2020-03-10 21:41 ` [Intel-gfx] [PATCH 01/10] PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS limit Francisco Jerez
2020-03-11 12:42 ` Peter Zijlstra
2020-03-11 19:23 ` Francisco Jerez
2020-03-11 19:23 ` [Intel-gfx] [PATCHv2 " Francisco Jerez
2020-03-19 10:25 ` Rafael J. Wysocki
2020-03-10 21:41 ` [Intel-gfx] [PATCH 02/10] drm/i915: Adjust PM QoS response frequency based on GPU load Francisco Jerez
2020-03-10 22:26 ` Chris Wilson
2020-03-11 0:34 ` Francisco Jerez
2020-03-18 19:42 ` Francisco Jerez
2020-03-20 2:46 ` Francisco Jerez
2020-03-20 10:06 ` Chris Wilson
2020-03-11 10:00 ` Tvrtko Ursulin
2020-03-11 10:21 ` Chris Wilson
2020-03-11 19:54 ` Francisco Jerez
2020-03-12 11:52 ` Tvrtko Ursulin
2020-03-13 7:39 ` Francisco Jerez
2020-03-16 20:54 ` Francisco Jerez
2020-03-10 21:41 ` [Intel-gfx] [PATCH 03/10] OPTIONAL: drm/i915: Expose PM QoS control parameters via debugfs Francisco Jerez
2020-03-10 21:41 ` [Intel-gfx] [PATCH 04/10] Revert "cpufreq: intel_pstate: Drop ->update_util from pstate_funcs" Francisco Jerez
2020-03-19 10:45 ` Rafael J. Wysocki
2020-03-10 21:41 ` [Intel-gfx] [PATCH 05/10] cpufreq: intel_pstate: Implement VLP controller statistics and status calculation Francisco Jerez
2020-03-19 11:06 ` Rafael J. Wysocki
2020-03-10 21:41 ` [Intel-gfx] [PATCH 06/10] cpufreq: intel_pstate: Implement VLP controller target P-state range estimation Francisco Jerez
2020-03-19 11:12 ` Rafael J. Wysocki
2020-03-10 21:42 ` [Intel-gfx] [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts Francisco Jerez
2020-03-17 23:59 ` Pandruvada, Srinivas
2020-03-18 19:51 ` Francisco Jerez
2020-03-18 20:10 ` Pandruvada, Srinivas
2020-03-18 20:22 ` Francisco Jerez
2020-03-23 20:13 ` Pandruvada, Srinivas [this message]
2020-03-10 21:42 ` [Intel-gfx] [PATCH 08/10] cpufreq: intel_pstate: Enable VLP controller based on ACPI FADT profile and CPUID Francisco Jerez
2020-03-19 11:20 ` Rafael J. Wysocki
2020-03-10 21:42 ` [Intel-gfx] [PATCH 09/10] OPTIONAL: cpufreq: intel_pstate: Add tracing of VLP controller status Francisco Jerez
2020-03-10 21:42 ` [Intel-gfx] [PATCH 10/10] OPTIONAL: cpufreq: intel_pstate: Expose VLP controller parameters via debugfs Francisco Jerez
2020-03-11 2:35 ` [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2) Pandruvada, Srinivas
2020-03-11 3:55 ` Francisco Jerez
2020-03-11 4:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2020-03-12 2:31 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for GPU-bound energy efficiency improvements for the intel_pstate driver (v2). (rev2) Patchwork
2020-03-12 2:32 ` Patchwork
2020-03-23 23:29 ` [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2) Pandruvada, Srinivas
2020-03-24 0:23 ` Francisco Jerez
2020-03-24 19:16 ` Francisco Jerez
2020-03-24 20:03 ` Pandruvada, Srinivas
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=c43ab3612650e359c04693b239bfd7ebef439ad3.camel@intel.com \
--to=srinivas.pandruvada@intel.com \
--cc=currojerez@riseup.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/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).