Bug 96521

Summary: intel pstate driver calculates frequency incorrectly
Product: Power Management Reporter: Doug Smythies (dsmythies)
Component: intel_pstateAssignee: Chen Yu (yu.c.chen)
Status: RESOLVED CODE_FIX    
Severity: normal CC: lenb, rui.zhang, szg00000, yu.c.chen
Priority: P3    
Hardware: All   
OS: Linux   
Kernel Version: 4.0rc7 and all previous. Subsystem:
Regression: No Bisected commit-id:
Attachments: proposed solution, taken from what Len is doing elsewhere

Description Doug Smythies 2015-04-12 17:04:56 UTC
Question: Why do turbostat Bzy_MHz and the CPU frequencies reported by the intel_pstate driver always seem to be different?

Answer: Because turbostat calculates it correctly and the intel_pstate driver does not.

This code, from intel_pstate_calc_busy:

        sample->freq = fp_toint(
                mul_fp(int_tofp(
                        cpu->pstate.max_pstate * cpu->pstate.scaling / 100),
                        core_pct));

basically assumes that tsc is an exact multiple of 100 MHz, which might not be true. For example on my computer (i7-2600K) tsc is 3411.127 MHz and the minimum frequency is 1605 MHz, which is what turbostat reports. intel_pstate reports 1599.9 MHz.

Question: Does it really matter?

Answer: When digging into subtle differences in response and energy, yes.

The suggestion is to do it the way turbostat does. It appears to read TSC from some register.
Comment 1 Kristen 2015-05-07 15:58:47 UTC
reducing priority to P3 - the user impact is small.
Comment 2 Chen Yu 2015-11-19 08:09:15 UTC
I saw a series of patches have been sent out for internal review, which will  remove sample->freq, and use tsc * aper/mperf for cpu freq calculation.
Comment 3 Chen Yu 2016-05-18 05:29:00 UTC
Fixed by 
commit ffb810563c0c049872a504978e06c8892104fb6c
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sun Apr 10 05:59:10 2016 +0200

    intel_pstate: Avoid getting stuck in high P-states when idle
Comment 4 Chen Yu 2016-05-18 05:44:44 UTC
Well, it has not been fixed for core platform but only for atom in get_target_pstate_use_cpu_load.
Comment 5 Doug Smythies 2016-06-19 15:56:27 UTC
Chen, ffb810563c0c049872a504978e06c8892104fb6c has nothing to do with this bug report. That commit is a result of work on bug 115771.
Comment 6 Len Brown 2017-04-04 00:08:06 UTC
sample.freq no longer exists in the upstream driver
is this still an issue?
Comment 7 Doug Smythies 2017-04-04 01:07:26 UTC
Yes, it is still an issue, and still for the exact reasons I originally listed. (well O.K. it does it a different way now, but it is the same basic calculation).
Comment 8 Doug Smythies 2017-07-26 21:31:56 UTC
Created attachment 257719 [details]
proposed solution, taken from what Len is doing elsewhere

Things have changed, or are changing. In the context of kernel 4.13-rc1, it might be that this bug report no longer makes sense. However, there is still the trace buffer CPU frequency sample information. It wouldn't make sense to change cpu->pstate.scaling because we want nice round numbers when setting max and min frequencies and such. So the proposal is to just fix the reported frequency in the trace data.
Comment 9 Chen Yu 2017-09-18 12:08:35 UTC
@Doug, thanks for your solution, may I know if this solution is still applicable for latest 4.14-rc1?(after dropped the PID?)
Comment 10 Doug Smythies 2017-09-18 15:33:38 UTC
@Yu : My patch is included in kernel 4.14-rc1. This bug report is solved.