Added Governors --
- Thanks to faux123
This is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling,
and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such.
Intellidemand does not jump to highest frequency when screen is off.
- Thanks to Ezekeel
The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand.
Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state
on a step overriding sampling interval.
Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always
select the maximum frequency while the screen is off.
- Thanks to Tegrak
Based on Interactive and Smartass. When workload is greater than or equal to 60%, the governor scales up
CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step.
When screen is off, frequency is locked to global scaling minimum frequency
- a "superbad" super smooth rendition of a highly optimized "smartass" governor!
- a "slightly more agressive smart" optimized governor!
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
Is a conservative-based governor. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
Badass removes all of this "fast peaking" to the max frequency. Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1024Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
Virtuous is a modded smartassV2 which gives even more battery time then smartassV2
Added Io-scheduler --
- Unlike other schedulers, synchronous and asynchronous requests are not treated separately,
instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
- Simple IO-Scheduler-
SIO is the default scheduler in this kernel. It is widely-regarded as the best all-round performing IO scheduler for android. It is low on CPU usage and optimized for flash-based storage. From the creator - "Based on Noop, Deadline and V(R) IO schedulers. This algorithm does not do any kind of sorting, as it is aimed for aleatory access devices, but it does some basic merging. We try to keep minimum overhead to achieve low latencies. Asynchronous and synchronous requests are not treated separately, but we rely on deadlines to ensure fairness."
- BFQ -
Budget Fair Queueing IO-Scheduler-
* Copyright (C) 2008 Fabio Checconi
* Paolo Valente
* Licensed under the GPL-2 as detailed in the accompanying COPYING.BFQ file.
* BFQ is a proportional share disk scheduling algorithm based on the
* slice-by-slice service scheme of CFQ. But BFQ assigns budgets,
* measured in number of sectors, to tasks instead of time slices.
* The disk is not granted to the active task for a given time slice,
* but until it has exahusted its assigned budget. This change from
* the time to the service domain allows BFQ to distribute the disk
* bandwidth among tasks as desired, without any distortion due to
* ZBR, workload fluctuations or other factors. BFQ uses an ad hoc
* internal scheduler, called B-WF2Q+, to schedule tasks according to
* their budgets. Thanks to this accurate scheduler, BFQ can afford
* to assign high budgets to disk-bound non-seeky tasks (to boost the
* throughput), and yet guarantee low latencies to interactive and
* soft real-time applications.