Linux-ACPI Archive on
 help / color / Atom feed
From: "Doug Smythies" <>
To: "'Rafael J. Wysocki'" <>,
	"'Pavel Machek'" <>
Cc: "'kernel list'" <>,
	"'ACPI Devel Maling List'" <>,
	"'Zhang, Rui'" <>,
	"'Rafael J. Wysocki'" <>,
	"'Viresh Kumar'" <>,
	"'Linux PM'" <>,
	"'Thomas Gleixner'" <>,
	"'Ingo Molnar'" <>,
	"'Borislav Petkov'" <>,
	"'H. Peter Anvin'" <>,
	"'the arch/x86 maintainers'" <>,
	"Doug Smythies" <>
Subject: RE: 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?
Date: Wed, 12 Jun 2019 16:39:04 -0700
Message-ID: <008f01d52178$07b3be70$171b3b50$@net> (raw)
In-Reply-To: <>

On 2019.06.12 14:25 Rafael J. Wysocki wrote:
> On Wed, Jun 12, 2019 at 4:45 AM Doug Smythies <> 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

  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 11:17 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
2019-06-12 21:44   ` Rafael J. Wysocki
2019-06-12 23:39     ` Doug Smythies [this message]
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 publically 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:

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

  git send-email \
    --in-reply-to='008f01d52178$07b3be70$171b3b50$@net' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ACPI Archive on

Archives are clonable:
	git clone --mirror linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ \
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox