Hi Doug, On Thu, Feb 11, 2016 at 11:50 PM, Doug Smythies <dsmyth...@telus.net> wrote: > On 2016.02.10 15:18 Rafael J. Wysocki wrote: >> On Wednesday, February 10, 2016 03:11:43 PM Doug Smythies wrote: >>> On 2016.02.10 07:17 Rafael J. Wysocki wrote: >>>> On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote: >>>>> >>> This patch set solves a long standing issue with the intel_pstate driver. > >> Good to hear that, thanks! > >>> The issue began with the introduction of the "duration" method for deciding >>> if the CPU had been idle for a long time resulting in forcing the >>> target pstate downwards. Often this was the correct action, but sometimes >>> this >>> was the wrong thing to do, because the cpu was actually very busy, but just >>> so >>> happened to be idle on jiffy boundaries (perhaps similar to what Steve >>> Muckle >>> was referring to on another branch of this thread). > >>> I have a bunch of graphs, if anyone wants to see the supporting data. > >> It would be good to see how the data with and without the patchset compare >> to each other if you have that. > > Please see: > double u double u double u dot smythies dot com > /~doug/linux/intel_pstate/rjw_patch_set/index.html
Thanks for the data. > Specific duration tests graphs are posted, and also a bunch of idle tests > graphs are posted. > The references section includes links to all raw and post processed data. > > Note that on my 2 hour idle tests, I had a few 300 second durations > on CPU 6 with the v5 patch set. > (likely what Steve Muckle was referring to.) > Such long durations did not occur in v6 or v7 2 hour idle tests. OK, that suggests that using rq_lock(rq) in patch [1/3] is a win. > Very interesting patterns in the 2 hour idle tests durations for > individual CPUs. > > On 2016.02.10 22:03 Srinivas Pandruvada wrote: > >>> My test computer has an older model i7 (Intel(R) Core(TM) i7-2600K CPU @ >>> 3.40GHz) >> Thanks Doug. If you have specific workloads, please compare performance. > > My work so far has been testing functionality, with unrealistic workloads > specifically > designed to exaggerate issues, in this case the duration problem. > > I'll look at some real world workload scenarios. > > What I do have from my 2 hour idle tests is the of total number of passes > through > the intel_pstate driver: > > Control sample: Kernel 4.3-rc3: 37949 passes. > Kernel 4.3-rc3 + rjw 3 patch set v5: 180355 passes > Kernel 4.3-rc3 + rjw 3 patch set v6: 201307 passes > Kernel 4.3-rc3 + rjw 3 patch set v7: 203619 passes That reflects how things work with the changes. The driver is called more often now and has to decide whether or not to take a sample. It would be interesting to see how many of those were samples that were actually taken if you can instrument that. > While I should have, I did not run turbostat to get idle energy and/or power. > However, a 1 hour idle test with turbostat gave (Package Joules): > Control sample: Kernel 4.3-rc3: 13788 J or 3.83 Watts > Kernel 4.3-rc3 + rjw 3 patch set v7: 13929 J or 3.87 Watts So it shows a slight increase in energy consumption with your workloads. It is not as much as to make me worry in any way, but I'm wondering if performance is better too as a result (and how much better if so). Thanks, Rafael
