lkml.org 
[lkml]   [2019]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?
Date
On 2019.06.12 14:25 Rafael J. Wysocki wrote:
> On Wed, Jun 12, 2019 at 4:45 AM Doug Smythies <dsmythies@telus.net> wrote:
>>
>> So, currently there seems to be 3 issues in this thread
>> (and I am guessing a little, without definitive data):
>>
>> 1.) On your system Kernel 5.4-rc2 (or 4) defaults to the intel_pstate CPU frequency
>> scaling driver and the powersave governor, but kernel 4.6 defaults to the
>> acpi-cpufreq CPU frequency scaling driver and the ondemand governor.
>
> Which means that intel_pstate works in the active mode by default and
> so it uses its internal governor.

Note sure what you mean by "internal governor"?
If you meant HWP (Hardware P-state), Pavel's processor doesn't have it.
If you meant the active powersave governor code within the driver, then agreed.

> That governor is more performance-oriented than ondemand and it very
> well may cause more power to be allocated for the processor - at the
> expense of the GPU.

O.K. I mainly use servers and so have no experience with possible GPU
verses CPU tradeoffs.

However, I did re-do my tests measuring energy instead of CPU frequency
and found very little difference between the acpi-cpufreq/ondemand verses
intel_pstate/powersave as a function of single threaded load. Actually,
I did the test twice, one at 20 hertz work/sleep frequency and also
at 67 hertz work/sleep frequency. (Of course, Pavel's processor might
well have a different curve, but it is a similar vintage to mine
i5-2520M verses i7-2600K.) The worst difference was approximately
1.1 extra processor package watts (an extra 5.5%) in the 80% to 85%
single threaded load range at 67 hertz work/sleep frequency for
the intel-pstate/powersave driver/governor.

What am I saying? For a fixed amount of work to do per work/sleep cycle
(i.e. maybe per video frame related type work) while the CPU frequency Verses load
curves might differ, the resulting processor energy curve differs much less.
(i.e. the extra power for higher CPU frequency is for less time because it gets
the job done faster.) So, myself, I don't yet understand why only the one method
would have hit thermal throttling, but not the other (if indeed it doesn't).
Other differences between kernel 4.6 and 5.2-rc? might explain it. I did all
my tests on kernel 5.2-rc3, except that one example from kernel 4.4 on my
earlier reply, so that were not other variables than CPU scaling driver and
governor changes.

> The lower-than-expected frame rate may result from that, in principle.

> One way to mitigate that might be to use intel_pstate in the passive
> mode (pass intel_pstate=passive to the kernel in the command line)
> along with either ondemand or schedutil as the governor.

The CPU frequency verses load curves for this those two governors are very similar
for both the acpi_cpufreq and intel_cpufreq (which is the intel_pstate driver
in passive mode) drivers.

Just for information: CPU frequency verses single threaded load curves
for the conservative governor is quite different between the two drivers.
(tests done in February, perhaps I should re-do and also look at energy
at the same time, or instead of CPU frequency.)

... Doug


\
 
 \ /
  Last update: 2019-06-13 19:02    [W:0.102 / U:1.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site