linux-kernel - RE: [PATCH] cpufreq: intel_pstate: Fix rounding of core

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:	Wed, 11 Jun 2014 23:56:33 -0700
From:	"Doug Smythies" <dsmythies@...us.net>
To:	"'Rafael J. Wysocki'" <rafael@...nel.org>
Cc:	"'Stratos Karafotis'" <stratosk@...aphore.gr>,
	<linux-pm@...r.kernel.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
	"'Rafael J. Wysocki'" <rjw@...ysocki.net>,
	<viresh.kumar@...aro.org>, <dirk.j.brandewie@...el.com>
Subject: RE: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct


On 2014.06.11 14:45 Rafael J. Wysocki wrote:
> On Wed, Jun 11, 2014 at 11:40 PM, Doug Smythies <dsmythies@...us.net> wrote:
>
>> Myself, I consider the issue of excessive deferred timer times to be a much higher priority (see my on-list e-mail from Monday). Correct me if I am wrong.
>> Even without the "excessive" part, and for a 250 Hz kernel, the current kick in point can be hit routinely, unduly biasing the CPU frequency downwards.
>> A random example (250 Hz kernel): 23% load at 25 Hertz load / sleep frequency for 300 total seconds.
>>
>> Duration histrogram:
>>
>> Occurrences duration (seconds)
>>      16 0.044
>>      39 0.024
>>      45 0.028
>>      46 0.016
>>      48 0.032
>>      61 0.036
>>     166 0.012
>>     198 0.020
>>    7166 0.040
>>
>> Where you can see that the majority of the time the duration is such that the code will force the CPU frequency downwards.
>> It runs at minimum pstate instead of maximum pstate where it should be.

> I see.
> What would you suggest to do to address this problem, then?

The above specific example can be solved by increasing the kick in factor from "sample_rate * 3" to something more.

As mentioned in my e-mail of Monday, I do not know how to proceed further with investigating the excessive deferral issue.

There are some ideas (I think originally from Dirk) that wouldn't involve "[PATCH 3/4] intel_pstate: add sample time scaling" at all, but so far they have had issues also. There is something I would like to try, but it will take at least a few days.

... Doug


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/