cpufreq governor should respect AC/battery state
Reported by
realgran...@gmail.com,
May 27 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 9460.50.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.71 Safari/537.36 Platform: 9460.50.0 (Official Build) beta-channel cave Steps to reproduce the problem: 1. Use a chromebook with intel m cpu 2. Plug it on AC 3. What is the expected behavior? The performance is increased by switching the governor profile to "performance" unlocking the 3.1 GHz turbo What went wrong? Nothing happens to governor/cpufreq, still on 0.5-2.x GHz range on average. Did this work before? N/A Chrome version: 59.0.3071.71 Channel: beta OS Version: 9460.50.0 Flash Version: Shockwave Flash 26.0 r0 Switching to "performance" profile increases perceived responsiveness almost 2x. Because of this I have a shell window open to switch between profiles from cmdline every time I am on AC power.
,
Jun 3 2017
,
Jun 3 2017
Questions: - what benchmark / workload are you running to measure the perceived latency improvements? - which Chromebook?
,
Jun 3 2017
,
Jun 3 2017
,
Jun 3 2017
I have an m7 Acer C302. The biggest difference I am seeing is while working with Wolfram Cloud Mathematica web client - the interface is much more snappier. Also I can see this while browsing "heavy" websites (may be due to faster zram-swapping but I am not sure) If I monitor CPU frequency - it just never gets to 3.1GHz in "powersave" mode largely underperforming the chip I am sure a benchmark can be crafted for this: it should do something like testing js workloads that have <1s run time. In case I get some spare time I will try to make one. I've been running with performance governor for some time now and I should say that thermal design of this particular chromebook does not allow it for running in tablet mode for prolonged time with performance governor - the system just overheated and shut down (while doing intensive video/web surfing). Laptop mode works perfectly fine and powersave governor also works great in tablet mode. I may suspect OEM knew the thermal design deficiencies here and has deliberately clocked down the chip...
,
Jun 8 2017
I shall state that if intel Pstate PID tuning has ever been done, it is wrong for at least m7 and at least ASUS C302. I suspect other systems are affected too. I am not in a position to develop a new SNB but one should look at section "Tuning Intel P-State driver" of https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt and propose a set of parameters that will let us enjoy the full performance while not overheating the hardware by forcing it into "performance" governor permanently. Speaking of benchmarks, "octane score" should ideally not show any difference between powersave and performance governors with the correctly tuned PID
,
Jun 20 2017
OK running the Intel m7 cave laptop with cpu governor set to "performance" even in mild ambient temperature conditions at max load results in INFO DPTF[2110]: INFO:[<ACTION>ActionSystemSet@esif_uf_action_system.c#138]<1497961049346 ms>: SYSTEM_SHUTDOWN command received - temperature = 3692, trip point = 3682 after about 30 seconds of continuous max load. I guess this issue can be closed with WONTFIX since squeezing maximum performance from the chip is probably OEM task rather than OS support team and if OEM has failed to supply SNB with better performance curve one can barely do anything without investing much time in modeling hardware temperature profile.
,
Nov 7 2017
,
Nov 7
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 7
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by rohi...@chromium.org
, Jun 3 2017