| From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH 01/70] cpufreq: interactive: New 'interactive' governor | Date | Wed, 28 Oct 2015 01:59:01 +0100 |
| |
Hi,
On Tuesday, October 27, 2015 06:29:49 PM Bálint Czobor wrote: > From: Mike Chan <mike@android.com> > > This governor is designed for latency-sensitive workloads, such as > interactive user interfaces. The interactive governor aims to be > significantly more responsive to ramp CPU quickly up when CPU-intensive > activity begins. > > Existing governors sample CPU load at a particular rate, typically > every X ms. This can lead to under-powering UI threads for the period of > time during which the user begins interacting with a previously-idle system > until the next sample period happens. > > The 'interactive' governor uses a different approach. Instead of sampling > the CPU at a specified rate, the governor will check whether to scale the > CPU frequency up soon after coming out of idle. When the CPU comes out of > idle, a timer is configured to fire within 1-2 ticks. If the CPU is very > busy from exiting idle to when the timer fires then we assume the CPU is > underpowered and ramp to MAX speed. > > If the CPU was not sufficiently busy to immediately ramp to MAX speed, then > the governor evaluates the CPU load since the last speed adjustment, > choosing the highest value between that longer-term load or the short-term > load since idle exit to determine the CPU speed to ramp to. > > A realtime thread is used for scaling up, giving the remaining tasks the > CPU performance benefit, unlike existing governors which are more likely to > schedule rampup work to occur after your performance starved tasks have > completed. > > The tuneables for this governor are: > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: > The minimum amount of time to spend at the current frequency before > ramping down. This is to ensure that the governor has seen enough > historic CPU load data to determine the appropriate workload. > Default is 80000 uS. > /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load > The CPU load at which to ramp to max speed. Default is 85. > > Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585 > Signed-off-by: Mike Chan <mike@android.com> > Signed-off-by: Todd Poynor <toddpoynor@google.com> > Bug: 3152864 > Signed-off-by: Bálint Czobor <czoborbalint@gmail.com>
It's good to see that submitted, but it'll have to go through a detailed review which is going to take some time.
One my observation after a cursory look at it is that at least some later patches of the series modify drivers/cpufreq/cpufreq_interactive.c which is a new file added by the first patch. Is there any particular reason to avoid folding all of those patches into the first one?
Thanks, Rafael
|