Bug 177171
| Summary: | Reduced frequency window for conservative governor | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Nansa Ehadto (shontel84) |
| Component: | cpufreq | Assignee: | linux-pm (linux-pm) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rjw, viresh.kumar |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.8 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
My kernel config
cpufreq: conservative: Fix next frequency selection cpufreq: conservative: Fix next frequency selection |
||
Created attachment 241331 [details]
My kernel config
Also, git revert d352cf47d93e39494b44b792cca8d35a3a0bd9b3 appears to fix the problem on 4.8.1. So it is definitely this commit. Sorry for the breakage. Do I understand correctly that the governor doesn't select frequencies below 2000000 now, although it did that before? Yes, that is correct. Created attachment 241561 [details]
cpufreq: conservative: Fix next frequency selection
Does this patch make any difference?
Created attachment 241571 [details]
cpufreq: conservative: Fix next frequency selection
Sorry, one piece was missing in the previous patch.
Please test this one instead.
Yes, the patch fixes the issue. The frequencies are selected as expected. OK, thanks! I'll submit it to the mailing lists, then. Patch submitted: https://patchwork.kernel.org/patch/9373743/ Merged as commit abb6627910a1e783c8e034b35b7c80e5e7f98f41: http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=pm&id=abb6627910a1e783c8e034b35b7c80e5e7f98f41 |
Hello. Since 4.8 the conservative governor has a reduced frequency window on my machine (ThinkPad X250), despite correct values for scaling_{min,max}_freq $ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_{min,max}_freq 500000 2200000 The actual window became from 2000000 to 2200000 with accordingly more heating and more cpu fan activations, which is not optimal. I have bisected the problem to this commit: commit d352cf47d93e39494b44b792cca8d35a3a0bd9b3 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Jun 13 23:33:49 2016 +0200 cpufreq: conservative: Do not use transition notifications The conservative governor registers a transition notifier so it can update its internal requested_freq value if it falls out of the policy->min...policy->max range, but requested_freq is not really necessary. That value is used to track the frequency requested by the governor previously, but policy->cur can be used instead of it and then the governor will not have to worry about updating the tracked value when the current frequency changes independently (for example, as a result of min or max changes). Accodringly, drop requested_freq from struct cs_policy_dbs_info and modify cs_dbs_timer() to use policy->cur instead of it. While at it, notice that __cpufreq_driver_target() clamps its target_freq argument between policy->min and policy->max, so the callers of it don't have to do that and make additional changes in cs_dbs_timer() in accordance with that. After these changes the transition notifier used by the conservative governor is not necessary any more, so drop it, which also makes it possible to drop the struct cs_governor definition and simplify the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>