From: "Doug Smythies" <dsmythies@telus.net>
To: srinivas.pandruvada@linux.intel.com
Cc: rjw@rjwysocki.net, linux-pm@vger.kernel.org
Subject: RE: [RFC][PATCH 8 of 7] cpufreq: intel_pstate: add iir filter to pstate.
Date: Thu, 25 Aug 2016 10:00:40 -0700 [thread overview]
Message-ID: <000d01d1fef2$36ff5960$a4fe0c20$@net> (raw)
In-Reply-To: <1471907493-26639-1-git-send-email-dsmythies@telus.net>
Hi Srinivas:
On 2016.08.22 16:12 Doug Smythies wrote:
...[cut]...
+ *
+ * no clamps. Pre-filter clamping was needed in past implementations.
+ * To Do: Is any pre-filter clamping needed here? */
Yes, clamping is needed, otherwise, and for example, the target pstate
can "stick" low at high load for a few sample periods, until the filtered
value gets high enough. For the fix, I clamped the post-filter output value
(perhaps not in the best way, but for now):
doug@s15:~/temp-k-git/linux/drivers/cpufreq$ git diff
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ab5c004..56c09ef8f 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1307,6 +1307,7 @@ static inline int32_t get_target_pstate_default(struct cpudata *cpu)
int64_t scaled_gain, unfiltered_target;
int32_t busy_frac;
int pstate;
+ int max_perf, min_perf;
u64 duration_ns;
busy_frac = div_fp(sample->mperf, sample->tsc);
@@ -1399,6 +1400,14 @@ static inline int32_t get_target_pstate_default(struct cpudata *cpu)
cpu->sample.target = div_u64((int_tofp(100) - scaled_gain) *
cpu->sample.target + scaled_gain *
unfiltered_target, int_tofp(100));
+ /*
+ * Clamp the filtered value.
+ */
+ intel_pstate_get_min_max(cpu, &min_perf, &max_perf);
+ if (cpu->sample.target < int_tofp(min_perf))
+ cpu->sample.target = int_tofp(min_perf);
+ if (cpu->sample.target > int_tofp(max_perf))
+ cpu->sample.target = int_tofp(max_perf);
return fp_toint(cpu->sample.target + (1 << (FRAC_BITS-1)));
}
I'll send an updated patch in a few hours.
...[cut]...
+ *
+ * To Do: Often the actual pstate the system ran at over the last
+ * interval is not what was asked for, due to influence from
+ * other CPUs. It might make sense to use the average pstate
+ * (get_avg_pstate) as the old_output here (as per previous
+ * work by Philippe Longepe and Stephane Gasparini on the
+ * get_target_pstate_use_cpu_load method). Test it.
+ */
I have a version of this working. More on that it at a later date.
... Doug
prev parent reply other threads:[~2016-08-25 17:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-22 23:11 [RFC][PATCH 8 of 7] cpufreq: intel_pstate: add iir filter to pstate Doug Smythies
2016-08-25 17:00 ` Doug Smythies [this message]
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='000d01d1fef2$36ff5960$a4fe0c20$@net' \
--to=dsmythies@telus.net \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--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).