linux-kernel - Re: [PATCH v6 0/3] cpufreq: Replace timers with utilization update callbacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Feb 2016 02:20:16 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Doug Smythies <dsmythies@...us.net>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Juri Lelli <juri.lelli@....com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v6 0/3] cpufreq: Replace timers with utilization update callbacks

On Fri, Feb 12, 2016 at 2:02 AM, Doug Smythies <dsmythies@...us.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