lkml.org 
[lkml]   [2014]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct
Date

On 2014.06.11 14:45 Rafael J. Wysocki wrote:
> On Wed, Jun 11, 2014 at 11:40 PM, Doug Smythies <dsmythies@telus.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




\
 
 \ /
  Last update: 2014-06-12 09:41    [W:0.030 / U:14.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site