lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 28 Oct 2015 01:59:01 +0100 From: "Rafael J. Wysocki" <rjw@...ysocki.net> To: Bálint Czobor <czoborbalint@...il.com> Cc: Viresh Kumar <viresh.kumar@...aro.org>, linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, Mike Chan <mike@...roid.com>, Todd Poynor <toddpoynor@...gle.com> Subject: Re: [PATCH 01/70] cpufreq: interactive: New 'interactive' governor Hi, On Tuesday, October 27, 2015 06:29:49 PM Bálint Czobor wrote: > From: Mike Chan <mike@...roid.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@...roid.com> > Signed-off-by: Todd Poynor <toddpoynor@...gle.com> > Bug: 3152864 > Signed-off-by: Bálint Czobor <czoborbalint@...il.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists