linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Subject: Re: [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts.
Date: Tue, 17 Mar 2020 23:59:39 +0000	[thread overview]
Message-ID: <40db3c86c68abfab406618e2424787c18c119c87.camel@intel.com> (raw)
In-Reply-To: <20200310214203.26459-8-currojerez@riseup.net>

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?

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(~0L))) |
> +					 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(policy-
> >cpu);
>  		intel_pstate_hwp_set(policy->cpu);
>  	}

  reply	other threads:[~2020-03-17 23:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 21:41 [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2) Francisco Jerez
2020-03-10 21:41 ` [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       ` [PATCHv2 " Francisco Jerez
2020-03-19 10:25         ` Rafael J. Wysocki
2020-03-10 21:41 ` [PATCH 02/10] drm/i915: Adjust PM QoS response frequency based on GPU load Francisco Jerez
2020-03-10 22:26   ` [Intel-gfx] " 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 ` [PATCH 03/10] OPTIONAL: drm/i915: Expose PM QoS control parameters via debugfs Francisco Jerez
2020-03-10 21:41 ` [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 ` [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 ` [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 ` [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts Francisco Jerez
2020-03-17 23:59   ` Pandruvada, Srinivas [this message]
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
2020-03-10 21:42 ` [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 ` [PATCH 09/10] OPTIONAL: cpufreq: intel_pstate: Add tracing of VLP controller status Francisco Jerez
2020-03-10 21:42 ` [PATCH 10/10] OPTIONAL: cpufreq: intel_pstate: Expose VLP controller parameters via debugfs Francisco Jerez
2020-03-11  2:35 ` [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2) Pandruvada, Srinivas
2020-03-11  3:55   ` Francisco Jerez
2020-03-23 23:29 ` 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=40db3c86c68abfab406618e2424787c18c119c87.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 \
    --cc=rodrigo.vivi@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).