{"shas":[["2a8d299a3243a7f350b2f107707fc5c0732432d4","a17fed27eaa842282862ff7c1b9c8395a26ac320@android.com","cpufreq: interactive: New 'interactive' governor\n\nNew interactive governor.\n\nThis governor is designed for latency sensitive workloads, UI interaction for\nexample.\n\nAdvantages:\n+ significantly more responsive to ramp cpu up when required (UI interaction)\n+ more consistent ramping, existing governors do their cpu load sampling in a\nworkqueue context, the 'interactive' governor does this in a timer context, which\ngives more consistent cpu load sampling.\n+ higher priority for cpu frequency increase, rt_workqueue is used for scaling\nup, giving the remaining tasks the cpu performance benefit, unlike existing\ngovernors which schedule rampup work to occur after your performance starved\ntasks have completed.\n\nExisting governors sample cpu load at a particular rate, typically\nevery X ms. Which can lead to under powering UI threads when the user has\ninteracted with an idle system until the next sample period happns.\n\nThe 'interactive' governor has a different approach. Instead of sampling the cpu\nat a specified rate, the governor will scale the cpu frequency up when coming\nout of idle. When the cpu comes out of idle, a timer is configured to fire\nwithin 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer\nfires then we assume the cpu is underpowered and ramp to MAX speed.\n\nIf the cpu was not 100% busy, then the governor evaluates the cpu load over the\nlast 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down\nto.\n\nThere is only one tuneable for this governor:\n/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:\n\tThe minimum ammount of time to spend at the current frequency before\n\tramping down. This is to ensure that the governor has seen enough\n\thistoric cpu load data to determine the appropriate workload.\n\tDefault is 5000 uS.\n\nSigned-off-by: Mike Chan <mike@android.com>\nChange-Id: I686d2f57b0ed9cbb73217403b7438be5719588d2\n\ncpufreq: interactive: Fix potential division by zero\n\ncpufreq: interactive: Changes to interactive governor\n\nChanges include:\n* May scale up to intermediate speeds after scaling down, rather than\nscale to max speed and then only scale down until max speed needed.\n\n* Tweaked thresholds at which max speed requested (previously CPU must\nhave been 100% busy since idle exit timer started, now will go max if at\nleast 85% busy) and default minimum sample time raised to 80ms. Tweaking\nbased on UI tests, still in progress.\n\n* SMP fixes.\n\n* Fixed attempted multiple delete of sysfs group on governor stop.\nSet a just-in-case-CPU-goes-busy-again timer even if nr_running == 0 at\ntimer function run time, but cancel if that CPU goes idle (and don't\nre-arm timer if that CPU is currently idle).\n\n* Re-evaluate speed if a CPU goes idle while above min speed (and no timer\ncurrently set) in case the platform requires all CPUs to be at the same\nspeed.\n\n* Realtime workqueues disappeared upstream, convert speed up workqueue to\na realtime task. Average scheduling latency measured significantly less\nthan WQ_HIGHPRI.\n\n* Timers are not deferrable, must wake CPU from idle, since we now\nre-evaluate speed for idle CPUs.\n\n* CPU load is computed from higher of short-term load since idle exit vs.\nlong-term load since last frequency change, to avoid dropping speed\nduring temporary dips in load on long-term-busy CPU.\n\n* Avoid 1 CPU starting new idle exit load eval interval in a race with\ntimer running on another CPU.\n\n* New fugly debugging printfs should be reworked or go away eventually.\n\nChange-Id: I606b5c1850637c35a7814309df12362d5c044825\nvia: https://review.source.android.com//#change,15809","Mike Chan"]],"repo":"bcnice20/speedy-2.6.32.21","actor":"bcnice20","ref":"refs/heads/master","size":1,"head":"2a8d299a3243a7f350b2f107707fc5c0732432d4","actor_gravatar":"8ac3ef8cecf6e920c914a1240d9491cb","push_id":27601114}