On Fri, Feb 12, 2016 at 2:02 AM, Doug Smythies <dsmyth...@telus.net> wrote: > On 2016.02.11 15:28 Rafael J. Wysocki wrote: >> On 2106.02.11 14:50 Doug Smythies wrote: > >>> 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. > > Opps. I didn't understand that point, and so only now looked more > closely at the code. > >> It would be interesting to see how many of those were samples that >> were actually taken if you can instrument that. > > So, those are samples that were taken. There is no trace information > acquired when the new code decides not to take a sample (or so is my > understanding from a quick look).
That's correct. The trace only covers the samples that were actually taken. > I did find a couple of cases where the duration (elapsed time between > samples on a given CPU) was less than the nominal sample time. The search > was not exhaustive. (Likely O.K. within expected jitter, just noting > is all. The post processing tools use the kernel clock to do the > calculation, as the duration calculated by the driver is not in the trace > data.) > > 2 hour idle test: v5 patch 9.955 mSec sample 10078 CPU 1 > 2 hour idle test: v7 patch 9.968 mSec sample 49476 CPU 3 > Duration load test: v7 patch 9.982 mSec sample 10997 CPU 2 OK, so the order of magnitude looks reasonable at least. Thanks, Rafael
