Linux Intel Pstate driver. Kernel 3.14 RC5 Dirk intel_pstate 3. WWW.Smythies.com
k315rc5dirk3_r1: CPU Frequency Verses load experiment: Powersave mode after a fresh boot.
Note: there is a math overflow issue in the above data set, summary. Action item for Doug: Figure out why and propose a fix.
Further note that other examples of math overflow might have been missed, as this one was only noticed, buried in the data, by accident. (Addendum: There are no other overflows).
The intel_pstate code includes Dirk's (private, not public) 8 patches, with this one additional change:
diff intel_pstate.c.315rc5.dirk2 intel_pstate.c.315rc5.dirk3
627c627
< if (duration_us > sample_time * 3) {
---
> if (duration_us > sample_time * 10) {
Overview:

Detail A - Start of Experiment:

Detail B - End of Experiment:

. While the increased threshold for forcing a lower target pstate should have resulted in less tendency to drive to lower CPU Frequency when there is actually some load, it did not. Why not?
. With the limited testing done so far, the lower C0 threshold limit seems to be the better of the two methods.
On the subject of the math overflow:
I think this code:
sample->freq = fp_toint( mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct)); sample->core_pct_busy = (int32_t)core_pct;
and due to the change of core_pct to int64_t, needs to change to this:
sample->core_pct_busy = (int32_t)core_pct; sample->freq = fp_toint( mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), sample->core_pct_busy));
or this:
sample->freq = fp_toint(
mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), (int32_t)core_pct));
sample->core_pct_busy = (int32_t)core_pct;
References:
Dirk's (3.15RC5) intel_pstate.c 3. (The 8 patches one, with the addition * 10 delay threshold instead of * 3).
Script used to ramp cpu load.
Script used to ramp cpu sleep / load frequency.
Program used to create load ramp script.
Program used to create sleep / load frequency script.
Consume Program.
CPU frequency monitoring program (CPU 7).