Hi, On Tuesday, October 27, 2015 06:29:49 PM Bálint Czobor wrote: > From: Mike Chan <[email protected]> > > 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 <[email protected]> > Signed-off-by: Todd Poynor <[email protected]> > Bug: 3152864 > Signed-off-by: Bálint Czobor <[email protected]>
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
