5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?
Hi!
When I start flightgear, I get framerates around 20 fps and cpu at 3GHz:
pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$
(Ok, fgfs is really only running at single core, so why do both cores run at 3GHz?)
But temperatures get quite high:
pavel@duo:~/bt$ sensors thinkpad-isa-0000 Adapter: ISA adapter fan1: 4485 RPM
coretemp-isa-0000
Adapter: ISA adapter Package id 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +91.0°C (high = +86.0°C, crit = +100.0°C)
And soon cpu goes to 1.5GHz range, with framerates going down to 12fps. That's a bit low.
Room temperature is 26Celsius.
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means it should be able to sustain both cores running at 2.5GHz?
Any ideas? Were there any recent changes in that area?
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
Quoted 29 lines
When I start flightgear, I get framerates around 20 fps and cpu at 3GHz:
pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$(Ok, fgfs is really only running at single core, so why do both cores run at 3GHz?)
But temperatures get quite high:
pavel@duo:~/bt$ sensors thinkpad-isa-0000 Adapter: ISA adapter fan1: 4485 RPMcoretemp-isa-0000
Adapter: ISA adapter Package id 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +91.0°C (high = +86.0°C, crit = +100.0°C)And soon cpu goes to 1.5GHz range, with framerates going down to 12fps. That's a bit low.
Quoted 6 lines
Room temperature is 26Celsius.
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means it should be able to sustain both cores running at 2.5GHz?
Any ideas? Were there any recent changes in that area?
I tried kernel compile. It keeps both cores at 3GHz, temperature goes up over 95C, and then cpus start going down to 2.3GHz... and then down to 2GHz... and down to 1.9GHz.
watch bash -c 'sensors; cat /proc/cpuinfo | grep MHz'
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
Quoted 34 lines
Quoted 34 lines
When I start flightgear, I get framerates around 20 fps and cpu at 3GHz:
pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$(Ok, fgfs is really only running at single core, so why do both cores run at 3GHz?)
But temperatures get quite high:
pavel@duo:~/bt$ sensors thinkpad-isa-0000 Adapter: ISA adapter fan1: 4485 RPMcoretemp-isa-0000
Adapter: ISA adapter Package id 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +91.0°C (high = +86.0°C, crit = +100.0°C)And soon cpu goes to 1.5GHz range, with framerates going down to 12fps. That's a bit low.
Room temperature is 26Celsius.
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means it should be able to sustain both cores running at 2.5GHz?
Quoted 7 lines
Quoted 1 line
Any ideas? Were there any recent changes in that area?
I tried kernel compile. It keeps both cores at 3GHz, temperature goes up over 95C, and then cpus start going down to 2.3GHz... and then down to 2GHz... and down to 1.9GHz.
watch bash -c 'sensors; cat
/proc/cpuinfo| grep MHz'
Situation is very different with v4.6 distro based kernel.
CPU MHz is only getting values round to 100MHz. It does not go above 2.5GHz, but it does not go below 2.5GHz under the load, either.
ACPI adapter appears in sensors output.
Now I tried going to 5.2-rc4. It behaves the same as 5.2-rc2. Goes up to 3GHz briefly but then down to 2.0GHz and below under load.
Ideas welcome.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 49 lines · Pavel Machek
Hi!
Quoted 34 lines
Quoted 34 lines
When I start flightgear, I get framerates around 20 fps and cpu at 3GHz:
pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$(Ok, fgfs is really only running at single core, so why do both cores run at 3GHz?)
But temperatures get quite high:
pavel@duo:~/bt$ sensors thinkpad-isa-0000 Adapter: ISA adapter fan1: 4485 RPMcoretemp-isa-0000
Adapter: ISA adapter Package id 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +91.0°C (high = +86.0°C, crit = +100.0°C)And soon cpu goes to 1.5GHz range, with framerates going down to 12fps. That's a bit low.
Room temperature is 26Celsius.
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means it should be able to sustain both cores running at 2.5GHz?
Quoted 7 lines
Quoted 1 line
Any ideas? Were there any recent changes in that area?
I tried kernel compile. It keeps both cores at 3GHz, temperature goes up over 95C, and then cpus start going down to 2.3GHz... and then down to 2GHz... and down to 1.9GHz.
watch bash -c 'sensors; cat
/proc/cpuinfo| grep MHz'Situation is very different with v4.6 distro based kernel.
CPU MHz is only getting values round to 100MHz. It does not go above 2.5GHz, but it does not go below 2.5GHz under the load, either.
Quoted 6 lines
ACPI adapter appears in sensors output.
Now I tried going to 5.2-rc4. It behaves the same as 5.2-rc2. Goes up to 3GHz briefly but then down to 2.0GHz and below under load.
Ideas welcome.
What is the cpufreq governor for v4.6 and v5.2-rc4?
Signature · 5 lines
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
Quoted 48 lines · Pavel Machek
Hi!
Quoted 46 lines
Quoted 33 lines
When I start flightgear, I get framerates around 20 fps and cpu at
3GHz:pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$(Ok, fgfs is really only running at single core, so why do both cores
run at 3GHz?)But temperatures get quite high:
pavel@duo:~/bt$ sensors thinkpad-isa-0000 Adapter: ISA adapter fan1: 4485 RPMcoretemp-isa-0000
Adapter: ISA adapter
Package id 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +98.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +91.0°C (high = +86.0°C, crit = +100.0°C)And soon cpu goes to 1.5GHz range, with framerates going down to 12fps. That's a bit low.
Quoted 7 lines
Room temperature is 26Celsius.
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means
it should be able to sustain both cores running at 2.5GHz?Any ideas? Were there any recent changes in that area?
I tried kernel compile. It keeps both cores at 3GHz, temperature goes
up over 95C, and then cpus start going down to 2.3GHz... and then down
to 2GHz... and down to 1.9GHz.
Quoted 7 lines
Quoted 1 line
watch bash -c 'sensors; cat
/proc/cpuinfo| grep MHz'Situation is very different with v4.6 distro based kernel.
CPU MHz is only getting values round to 100MHz. It does not go above 2.5GHz, but it does not go below 2.5GHz under the load, either.
ACPI adapter appears in sensors output.
what temperature does coretemp report?
can you please provide the sensors output in 4.6 during kernel compiling?
can you attach the output of "grep . /sys/class/thermal/thermal*/*" when the temperature goes high in both kernels?
thanks,
rui
Quoted 9 lines
Now I tried going to 5.2-rc4. It behaves the same as 5.2-rc2. Goes up to 3GHz briefly but then down to 2.0GHz and below under load.
Ideas welcome.
Best regards,
Pavel
Hi!
I'm trying to provide all the required info below. Any ideas?
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means
it should be able to sustain both cores running at 2.5GHz?Any ideas? Were there any recent changes in that area?
I tried kernel compile. It keeps both cores at 3GHz, temperature goes
up over 95C, and then cpus start going down to 2.3GHz... and then down
to 2GHz... and down to 1.9GHz.
Quoted 6 lines
what temperature does coretemp report?
can you please provide the sensors output in 4.6 during kernel compiling?can you attach the output of "grep .
/sys/class/thermal/thermal*/*" when the temperature goes high in both kernels?
v5.2:
bash -c sensors; cat /proc/cpuinfo
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 4493 RPM
coretemp-isa-0000
Adapter: ISA adapter Package id 0: +97.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +97.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +94.0°C (high = +86.0°C, crit = +100.0°C)
cpu MHz : 2351.857
cpu MHz : 2351.920
cpu MHz : 2351.980
cpu MHz : 2352.036
pavel@duo:~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor powersave powersave powersave powersave pavel@duo:~$ grep . /sys/class/thermal/thermal*/* 2> /dev/null /sys/class/thermal/thermal_zone0/available_policies:step_wise /sys/class/thermal/thermal_zone0/mode:enabled /sys/class/thermal/thermal_zone0/passive:0 /sys/class/thermal/thermal_zone0/policy:step_wise /sys/class/thermal/thermal_zone0/temp:96000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:99000 /sys/class/thermal/thermal_zone0/trip_point_0_type:critical /sys/class/thermal/thermal_zone0/type:acpitz pavel@duo:~$
v4.6:
acpitz-virtual-0
Adapter: Virtual device
temp1: +96.0°C (crit = +99.0°C)
coretemp-isa-0000
Adapter: ISA adapter Physical id 0: +97.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +97.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +94.0°C (high = +86.0°C, crit = +100.0°C)
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 4493 RPM
cpu MHz : 2501.000
cpu MHz : 2501.000
cpu MHz : 2501.000
cpu MHz : 2501.000
pavel@duo:~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor ondemand ondemand ondemand ondemand
pavel@duo:~$ grep . /sys/class/thermal/thermal*/* 2> /dev/null /sys/class/thermal/thermal_zone0/available_policies:step_wise /sys/class/thermal/thermal_zone0/mode:enabled /sys/class/thermal/thermal_zone0/passive:0 /sys/class/thermal/thermal_zone0/policy:step_wise /sys/class/thermal/thermal_zone0/temp:96000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:99000 /sys/class/thermal/thermal_zone0/trip_point_0_type:critical /sys/class/thermal/thermal_zone0/type:acpitz pavel@duo:~$
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 7 lines · Pavel Machek
v5.2:
pavel@duo:~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor powersave powersave powersave powersave
Quoted 7 lines
v4.6:
pavel@duo:~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor ondemand ondemand ondemand ondemand
Hmm, the governors are different. But powersave should have picked the lowest frequency always.
What about cpufreq driver ?
cat /sys/devices/system/cpu/*/cpufreq/scaling_driver
Signature · 1 line
viresh
Hi,
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.
Suggest to check the related kernel configuration parameters.
$ grep -A 10 -i "CPU frequency scaling drivers" .config # CPU frequency scaling drivers # CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ_CPB=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_AMD_FREQ_SENSITIVITY=m CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_P4_CLOCKMOD=m
2.) With kernel 5.2-rc2 there is thermal throttling (thermald?), but for Kernel 4.6 it either doesn't hit the throttling threshold or is not enabled.
I don't have input here.
However note that the CPU frequency verses load graphs are quite different between acpi-cpufreq/ondemand and intel-pstate/powersave, with higher CPU frequencies at lower loads for the acpi-cpufreq driver and higher CPU frequencies at higher loads for the intel_pstate driver. The crossover point is about 35% load. So, the two driver/governors might well end up at different operating pointing terms of CPU frequencies. I do not have energy data for the CPU frequency verses load tests, which is really what matters.
3.) The older kernel is still using the older acpi-cpufreq stuff where some CPU frequency memory registers show what was asked for and not what the system is actually giving.
See below.
Quoted 10 lines · On 2019.06.09 04:18 Pavel Machek wrote:
When I start flightgear, I get framerates around 20 fps and cpu at 3GHz:
pavel@duo:~/bt$ cat /proc/cpuinfo | grep MHz cpu MHz : 3027.471 cpu MHz : 2981.863 cpu MHz : 2958.352 cpu MHz : 2864.001 pavel@duo:~/bt$
Quoted 2 lines
(Ok, fgfs is really only running at single core, so why do both cores run at 3GHz?)
There is only 1 PLL (Phase Locked Loop) master clock generator in your processor. Basically, the CPU with the highest frequency demand wins. What is not shown in your data is that the not busy core is also probably in a deep idle state for most of the time, consuming little or no energy. Below is an example from my processor (i7-2600K) using turbostat (note C6 is my deepest idle state, and only it is shown for simplicity):
Core CPU Busy% Bzy_MHz CPU%c6 PkgTmp PkgWatt - - 12.52 3799 74.88 54 23.87 0 0 0.05 3664 99.89 54 23.87 0 4 0.00 3695 1 1 0.07 3676 99.87 1 5 0.00 3667 2 2 0.09 3669 99.78 2 6 0.00 3666 3 3 0.04 3786 0.00 3 7 99.92 3800
Observe the busy core spending no time in C6, but the other 3
spend most of the time there. However, for the little time that they are active, CPU 7 is the one demanding the high CPU frequency.
Anticipated question:
"Then why aren't all the CPU frequencies exactly the same?" My processor's max turbo frequency is a function of how many cores are active, and so actually varies under peak demand. Excerpt from turbostat, not in quiet mode:
35 * 100.0 = 3500.0 MHz max turbo 4 active cores
36 * 100.0 = 3600.0 MHz max turbo 3 active cores
37 * 100.0 = 3700.0 MHz max turbo 2 active cores
38 * 100.0 = 3800.0 MHz max turbo 1 active cores
Quoted 2 lines
The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means it should be able to sustain both cores running at 2.5GHz?
No, that is more a function of your hardware's ability (or lack of) to move the waste heat away.
Quoted 4 lines
Situation is very different with v4.6 distro based kernel.
CPU MHz is only getting values round to 100MHz. It does not go above 2.5GHz, but it does not go below 2.5GHz under the load, either.
Yes, it is going above 2.5 GHz, see below.
Quoted 6 lines
v4.6:
cpu MHz : 2501.000
cpu MHz : 2501.000
cpu MHz : 2501.000
cpu MHz : 2501.000
That seems to be the old acpi-cpufreq information, which is telling you what it's asking for and not what it actually is. And the "01" means it is asking for turbo range frequencies. Example from my system, while running the above CPU 7 busy test:
Conditions: Old kernel (4.4), acpi-cpufreq driver, ondemand gov.
doug@s15:~$ grep MHz /proc/cpuinfo cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 1600.000 cpu MHz : 3401.000
CPUs 0-6 have very little load and are asking for the minimum available frequency. CPU 7 is asking for turbo.
The turbostat data tells a different story.
Conditions: New kernel (5.2-rc3), acpi-cpufreq driver, ondemand gov.
doug@s15:~$ grep MHz /proc/cpuinfo cpu MHz : 3611.623 cpu MHz : 3638.843 cpu MHz : 3662.703 cpu MHz : 3634.156 cpu MHz : 3611.601 cpu MHz : 3668.422 cpu MHz : 3611.471 cpu MHz : 3738.445
Conditions: New kernel (5.2-rc3), intel_pstate driver, powersave gov.
doug@s15:~$ grep MHz /proc/cpuinfo cpu MHz : 3651.506 cpu MHz : 3643.422 cpu MHz : 3611.678 cpu MHz : 3674.237 cpu MHz : 3612.469 cpu MHz : 3670.185 cpu MHz : 3612.050 cpu MHz : 3727.283
turbosat (tools/power/x86/turbostat/turbostat.c) commands used above:
sudo turbostat --quiet --hide IRQ,Avg_MHz,SMI,\
GFXMHz,TSC_MHz,GFXWatt,CorWatt,POLL%,CPU%c1,\
CPU%c3,CPU%c7,CoreTmp,GFX%rc6,Pkg%pc2,Pkg%pc3,\
Pkg%pc6,POLL,C1,C1E,C3,C6,C1%,C1E%,C3%,C6% \
--interval 5
And:
sudo turbostat
... Doug
Rafael J. Wysocki
maintainerQuoted 9 lines · Doug Smythies
Hi,
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_pstateCPU 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.
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.
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.
Quoted 11 lines · On 2019.06.12 14:25 Rafael J. Wysocki wrote:
Quoted 7 lines · Doug Smythies
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_pstateCPU 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_pstateworks 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.
Quoted 3 lines
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.
Quoted 5 lines
The lower-than-expected frame rate may result from that, in principle.
One way to mitigate that might be to use
intel_pstatein 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
Hi!
Quoted 35 lines · On 2019.06.12 14:25 Rafael J. Wysocki wrote:
Quoted 11 lines · Doug Smythies
Quoted 7 lines
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_pstateCPU 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_pstateworks 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.Quoted 3 lines
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.
Quoted 7 lines
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).
It seems there are serious differences in reporting :-(. How do I determine which frequency CPU really runs at, in 4.6 kernel?
But it seems that your assumptions are incorrect for my workload.
flightgear is single-threaded, and in my configuration saturates the CPU, because it would like to achieve higher framerate than my system is capable of.
Quoted 4 lines
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.)
So this might be my problem?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rafael J. Wysocki
maintainerQuoted 46 lines · Pavel Machek
Hi!
Quoted 35 lines · On 2019.06.12 14:25 Rafael J. Wysocki wrote:
Quoted 11 lines · Doug Smythies
Quoted 7 lines
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_pstateCPU 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_pstateworks 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.Quoted 3 lines
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.
Quoted 7 lines
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).
Quoted 2 lines
It seems there are serious differences in reporting :-(. How do I determine which frequency CPU really runs at, in 4.6 kernel?
With that kernel (and the acpi-cpufreq driver) the only way is to run your workload under turbostat.
Quoted 6 lines
But it seems that your assumptions are incorrect for my workload.
flightgear is single-threaded, and in my configuration saturates the CPU, because it would like to achieve higher framerate than my system is capable of.
Quoted 6 lines
Quoted 4 lines
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.)
So this might be my problem?
Not really, because you don't use the conservative governor. :-)
Generally, I agree with Doug that CPU performance scaling is unlikely to be the source of the symptom that you are observing.
Anyway, if you did what I had said previously (ie. run intel_pstate in the passive mode and use ondemand as the governor) and still see reduced frame rate (with respect to 4.6), that would basically rule CPU performance scaling out.
Cheers!
Rafael J. Wysocki
maintainerQuoted 11 lines · Doug Smythies
Quoted 9 lines · On 2019.06.12 14:25 Rafael J. Wysocki wrote:
Quoted 7 lines · Doug Smythies
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_pstateCPU frequency scaling driver and the powersave governor, but kernel 4.6 defaults to the acpi-cpufreq CPU frequency scaling driver and the ondemand governor.
Quoted 6 lines
Quoted 2 lines
Which means that
intel_pstateworks 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's what I mean.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 10 lines
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.
I see. Then this shouldn't matter.
Quoted 7 lines
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.
Right.
I personally doubt that any thermal throttling is involved here.
Quoted 6 lines
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.
Quoted 1 line
The lower-than-expected frame rate may result from that, in principle.
Quoted 7 lines
Quoted 3 lines
One way to mitigate that might be to use
intel_pstatein 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_cpufreqandintel_cpufreq(which is theintel_pstatedriver in passive mode) drivers.
That's what I would expect.
Cheers!
Quoted 1 line · On 2019.06.13 01:53 Rafael J. Wysocki wrote:
I personally doubt that any thermal throttling is involved here.
In earlier e-mails on this thread, Pavel showed his core and package temperatures as 97 and 98 degrees. If thermal throttling is not involved, it should be. The description of the observed CPU frequencies also matched my experiences with thermal throttling for the intel-pstate/powersave example. Myself, I can not determine if throttling is involved for the acpi-cpufreq/ondemand case, just from the clock frequencies, because,
at least on my system, it uses the kidle_inject method instead of the pstate method.
I continued doing experiments, enabling thermald (normally disabled on my system) and forcing thermal throttling on my test server. My system never gets hot enough, so I used a low trip point of 55 degrees.
The intel_pstate/powersave and intel_cpufreq/ondemand, which both used the pstate method, outperformed the acpi-cpufreq/ondemand by 30%, in a constant thermal throttling mode. This seems the opposite of Pavel's results, if indeed his system is thermal throttling. (I can write these experiments up in more detail if desired.)
Quoted 1 line · On 2019.06.13 Pavel Machek wrote:
But it seems that your assumptions are incorrect for my workload.
Fair enough. I don't have the appropriate hardware for this, and am trying to guess at a similar workflow for testing. Perhaps, just mudding things here rather than helping.
Quoted 4 lines
flightgear is single-threaded, and in my configuration saturates the CPU, because it would like to achieve higher framerate than my system is capable of.
Are you sure? Use turbostat and observe. Example 1:
intel_cpufreq/ondemand, kernel 5.2-rc3, two 100% loads:
doug@s15:~$ sudo turbostat --quiet --hide IRQ,Avg_MHz,SMI,\
Quoted 3 lines
GFXMHz,TSC_MHz,CorWatt,CoreTmp,GFX%rc6,Pkg%pc2,Pkg%pc3,\
Pkg%pc6,POLL,C1,C1E,C3,C6,C1%,C1E%,C3%,C6% \
--interval 5
Core CPU Busy% Bzy_MHz POLL% CPU%c1 CPU%c3 CPU%c6 CPU%c7 PkgTmp PkgWatt GFXWatt - - 25.24 2780 0.00 25.70 0.01 49.05 0.00 56 23.82 0.12 0 0 1.62 2781 0.00 1.90 0.02 96.46 0.00 56 23.82 0.12 0 4 0.05 2833 0.00 3.47 1 1 100.00 2780 0.00 0.00 0.00 0.00 0.00 1 5 0.03 2893 0.00 99.97 2 2 0.03 2906 0.00 99.97 0.00 0.00 0.00 2 6 100.00 2780 0.00 0.00 3 3 0.07 2797 0.00 0.18 0.01 99.74 0.00 3 7 0.10 2834 0.00 0.14
Example 2:
acpi_cpufreq/ondemand, kernel 5.2-rc3, two 100% loads:
doug@s15:~$ sudo turbostat --quiet --hide IRQ,Avg_MHz,SMI,\
Quoted 3 lines
GFXMHz,TSC_MHz,CorWatt,CoreTmp,GFX%rc6,Pkg%pc2,Pkg%pc3,\
Pkg%pc6,POLL,C1,C1E,C3,C6,C1%,C1E%,C3%,C6% \
--interval 5
Core CPU Busy% Bzy_MHz POLL% CPU%c1 CPU%c3 CPU%c6 CPU%c7 PkgTmp PkgWatt GFXWatt - - 18.06 3069 0.00 18.45 0.01 63.47 0.00 55 21.50 0.12 0 0 15.55 3049 0.00 1.31 0.02 83.12 0.00 55 21.50 0.12 0 4 0.64 2651 0.00 16.22 1 1 62.43 3075 0.00 8.15 0.00 29.43 0.00 1 5 7.71 3068 0.00 62.81 2 2 50.56 3091 0.00 0.78 0.00 48.66 0.00 2 6 0.44 2346 0.00 50.89 3 3 2.30 2901 0.00 5.00 0.01 92.69 0.00 3 7 4.79 3016 0.00 2.49
With the additional C6 % coming from the kidle_inj tasks. Observation 1: The loaded CPUs migrate much more often in this scenario. Observation 2: While the package watts are different by over 2 watts, the long term (done over many hours) average was the same for all methods.
... Doug
Quoted 4 lines · Doug Smythies
Quoted 1 line · On 2019.06.13 01:53 Rafael J. Wysocki wrote:
I personally doubt that any thermal throttling is involved here.
Quoted 9 lines
In earlier e-mails on this thread, Pavel showed his core and package temperatures as 97 and 98 degrees. If thermal throttling is not involved, it should be. The description of the observed CPU frequencies also matched my experiences with thermal throttling for the intel-pstate/powersave example. Myself, I can not determine if throttling is involved for the acpi-cpufreq/ondemand case, just from the clock frequencies, because,
at least on my system, it uses thekidle_injectmethod instead of the pstate method.
Yes, I'm pretty sure it is thermal throttling. System is running > 3GHz when cold, and going below 2GHz when hot...
And I'm pretty sure the throttling works, too, because temperature goes to ~98C quickly, and stays there.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html