| Message ID | 1446542840-14982-2-git-send-email-philippe.longepe@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 2015.11.03 01:27 Philippe Longepe wrote: > Change the setpoint to 60 accordingly to the new core busy scaled formula. > The new formaula is based on the number of cycles per seconds > (average frequency) divided by the requested frequency. So, we need to > chose a setpoint more aggressive to improve performance. Myself, and so as to improve response to some games and such that use many threads and such but often a lower overall CPU load, I think the setpoint should be set a little lower. There is a tradeoff in reducing the setpoint further as it increases the noise and tendency to oscillate in the response curve. Ultimately, it may be desirable to introduce a little slope in the load / CPU frequency response curve. I have a bunch of graphs comparing response curves. [1] > > Measured with this parameter, we noticed an improvement in Browsermark > for power and perf compared to the old formula: I would like to try this test on my system. What is the exact test? Do I understand correctly, that I need a browser to do the test? (my test system is a server, and it doesn't have a browser.) > > Score without the patch: 3517 > Power without the patch: 6856 mW > > Score with the patch: 3719 > Power with the patch: 6265 mW There are some other Phoronix tests that we (the original maintainer and the a couple of others working with him used to use. See [1]. Please be aware that the last time I tried to bring back load based calculations, Kristen tested the proposed solution on some intel "specpower test bed and experienced a regression on haswell based server platforms vs. Dirks algorithm." I don't have any details. Your response curve, and in particular your step function response time, is different, so it might worth re-testing. References: [1] double u double u double u dot smythies dot com/~doug/linux/intel_pstate/philippe_longepe/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/11/2015 17:22, Doug Smythies wrote: > On 2015.11.03 01:27 Philippe Longepe wrote: > >> Change the setpoint to 60 accordingly to the new core busy scaled formula. >> The new formaula is based on the number of cycles per seconds >> (average frequency) divided by the requested frequency. So, we need to >> chose a setpoint more aggressive to improve performance. > Myself, and so as to improve response to some games and such that use > many threads and such but often a lower overall CPU load, I think the setpoint should be set a little lower. I have an idea to address these oscillating workload. I'm testing a patch on Android that detects these use cases (mainly GLThreads migrating are responsible for these oscillation). I'll submit it as soon as it gives the best power and performance trade-off. > > There is a tradeoff in reducing the setpoint further as it increases the noise > and tendency to oscillate in the response curve. Ultimately, it may be desirable > to introduce a little slope in the load / CPU frequency response curve. > > I have a bunch of graphs comparing response curves. [1] > >> Measured with this parameter, we noticed an improvement in Browsermark >> for power and perf compared to the old formula: > I would like to try this test on my system. What is the exact test? > Do I understand correctly, that I need a browser to do the test? > (my test system is a server, and it doesn't have a browser.) Yes, for browsermark, you can use this link but you need a browser: http://web.basemark.com/ Else you can try some gaming workloads (I was using CandyCrush on Android) to evaluate the power gain. > >> Score without the patch: 3517 >> Power without the patch: 6856 mW >> >> Score with the patch: 3719 >> Power with the patch: 6265 mW > There are some other Phoronix tests that we (the original maintainer and > the a couple of others working with him used to use. See [1]. > > Please be aware that the last time I tried to bring back load based calculations, > Kristen tested the proposed solution on some intel "specpower test bed and > experienced a regression on haswell based server platforms vs. Dirks > algorithm." I don't have any details. > Your response curve, and in particular your step function response time, > is different, so it might worth re-testing. > > References: > > [1] double u double u double u dot smythies dot com/~doug/linux/intel_pstate/philippe_longepe/index.html > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 421903f..43f0067 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -872,7 +872,7 @@ static struct cpu_defaults core_params = { .pid_policy = { .sample_rate_ms = 10, .deadband = 0, - .setpoint = 97, + .setpoint = 60, .p_gain_pct = 20, .d_gain_pct = 0, .i_gain_pct = 0,