lkml.org 
[lkml]   [2019]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?
On Thu, Jun 13, 2019 at 1:40 AM Doug Smythies <dsmythies@telus.net> wrote:
>
> 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's what I mean.

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

I see. Then this shouldn't matter.

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

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

That's what I would expect.

Cheers!

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