linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Pavel Machek'" <pavel@ucw.cz>
Cc: "'kernel list'" <linux-kernel@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>, <rui.zhang@intel.com>,
	<rjw@rjwysocki.net>, <viresh.kumar@linaro.org>,
	<linux-pm@vger.kernel.org>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <bp@alien8.de>, <hpa@zytor.com>,
	<x86@kernel.org>, "Doug Smythies" <dsmythies@telus.net>
Subject: RE: 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?
Date: Tue, 11 Jun 2019 19:37:17 -0700	[thread overview]
Message-ID: <007701d520c7$c397bda0$4ac738e0$@net> (raw)
In-Reply-To: <20190609111732.GA2885@amd>

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.

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$
>
> (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

> 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.

> 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.

> 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



  parent reply	other threads:[~2019-06-12  2:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 11:17 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related? Pavel Machek
2019-06-09 11:23 ` Pavel Machek
2019-06-09 12:12   ` Pavel Machek
2019-06-09 13:55     ` Daniel Lezcano
2019-06-09 14:13     ` Zhang Rui
2019-06-11 10:12       ` Pavel Machek
2019-06-11 10:15         ` Viresh Kumar
2019-06-12  2:37 ` Doug Smythies [this message]
2019-06-12 21:44   ` Rafael J. Wysocki
2019-06-12 23:39     ` Doug Smythies
2019-06-13  8:11       ` Pavel Machek
2019-06-13  9:00         ` Rafael J. Wysocki
2019-06-13  8:52       ` Rafael J. Wysocki
2019-06-18  8:20         ` Doug Smythies
2019-06-18  8:34           ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='007701d520c7$c397bda0$4ac738e0$@net' \
    --to=dsmythies@telus.net \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --cc=tglx@linutronix.de \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).