Bug 96521
| Summary: | intel pstate driver calculates frequency incorrectly | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Doug Smythies (dsmythies) |
| Component: | intel_pstate | Assignee: | 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 | ||
reducing priority to P3 - the user impact is small. 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. 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 Well, it has not been fixed for core platform but only for atom in get_target_pstate_use_cpu_load. Chen, ffb810563c0c049872a504978e06c8892104fb6c has nothing to do with this bug report. That commit is a result of work on bug 115771. sample.freq no longer exists in the upstream driver is this still an issue? 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). 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.
@Doug, thanks for your solution, may I know if this solution is still applicable for latest 4.14-rc1?(after dropped the PID?) @Yu : My patch is included in kernel 4.14-rc1. This bug report is solved. |
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.