[KT747: Share & discuss your settings]+[govs & scheds info]

Search This thread

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
4ff7d2fbb181f.png

It looks like this thread is starting to be way more popular than i expected when I created it! I decided to add useful OP to it.


Here is a list of a few things to know about how I want this thread to be:


  • First of all, everybody is more than welcome to share settings, knowledge or any useful informations that could help someone. XDA is all about helping each other.
  • No Question is too stupid. Feel free to ask anything that is related to the kernel. I specified KT747 in the title because this is what I personally use but any adjustement made to governors, schedulers and undervolting will work with different kernels that allow you to adjust those settings. So even if you don't use KT747, you're welcome to post here.
  • Before posting in this thread, read the entire OP and second post with useful links and informations.
  • Finally, be respectful and have fun!

How to share settings:
- Begin by telling what is your rom, the date or name of the release, jellybean or ics, AOSP or touchwiz, 4.1.2 or 4.2.1 and also specify which release of KT747 you are using or if you are using another kernel.
- Let us know your general settings: Min/Max frequencies, screen off profile(Mhz and/or governor) and vibration strength.
- Then share with us what governor and I/O scheduler you are using and if you made any adjustements to them.
- If you share adjustements you made on governors or schedulers, you can take screenshots or just write which tunables you change and what values you assigned to it.
- If you share undervolting settings, to avoid huge post with a lot of screenshots,we will do it differently: If you substracted the same amount of mV to every steps, just say how much. If you tweaked every steps separetly, you can type each voltages or you just make sure you have a backup of your settings, go into /sdcard/KTweaker/, copy the lines coresponding to the voltages and share it this way:
Voltage(from 2106 to 96 MHz):
1250 1225 1200 1175 1150 1125 1100 1085 1065 1045 1025 1005 985 965 945 925 905 890 875 860 845 830 815 800 790 780 770 760 750 745.
- To share your KTweaker backup file (/sdcard/KTweaker/). Specify if it is set on boot or not and if it has custom voltages. If you have custom undervoltage setting you better make a backup that is not set on boot or set on boot after 30 seconds. So if some device doesn't take your undervolt values they won't be stock in a bootloop.



Finally, Thanks to Ktoonsez for his amazing kernel that you can find here: http://xdaforums.com/showthread.php?t=1756776
You can Donate to Ktoonsez here: http://xdaforums.com/donatetome.php?u=4325945
 
Last edited:

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
Useful links and informations

Useful links and informations.

Informations about Governors:​

The following infos were found here:
http://xdaforums.com/showthread.php?t=1369817
http://xdaforums.com/showthread.php?p=28647926
http://xdaforums.com/showthread.php?t=1369817

Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings.

Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency.

Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations.

Intellidemand:
To sum up, 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.

Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.

Userspace:
Instead of automatically determining frequencies, lets user set frequencies.

Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).

Performance:
Sets min frequency as max frequency. Use this while benchmarking!

Scary:
A new governor wrote based on conservative with some smartass features

Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups.

Pegasusq:
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values ​​arranged.

MSM DCVS:
a very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements.

Abyssplug governor:
It is a modified Hotplug Governor: The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.

SLP governor:
It is a mix of pegasusq and ondemand


Governor tunables explanations​

OnDemand, Conservative, Ktoonservative, Adaptive, Intellidemand:
sampling_rate:Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
up_threshold: Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
powersave_bias: Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
sampling_down_factor: In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
down_differential: This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
freq_step: Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.

SmartassV2 & AssWax
awake_ideal_freq: The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
sleep_ideal_freq: The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
up_rate_us: The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
down_rate_us: The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
max_cpu_load: Same as up_threshold in other governors.
min_cpu_load: Same as down_threshold in other governors.
ramp_down_step: Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
ramp_up_step: Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
sleep_wakeup_freq: The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.

Interactive
hispeed_freq: Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
go_hispeed_load: Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
timer_rate:
The sample rate of the timer used to increase frequency.


PegasusQ:
cpu_up_rate: No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
cpu_down_rate: No of samples to evaluate load to scale CPU Down. After CPU_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
hotplug_freq_1_1: Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and run queue length is greater than hotplug_rq_1_1) Hotplug IN Second Core. Higher value correpsonds to delay in turning on second core.
UNIT: Kilo Hertz
hotplug_freq_2_0: Down threshold frequency to turn second core Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and run queue length is less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core. Lower value correpsonds to delay in turning off second core.
UNIT: Kilo Hertz
hotplug_rq_1_1: Threshold run queue length for second core to turn on.
UNIT: Positive Integer
hotplug_rq_2_0: Threshold run queue length for second core to turn off.
UNIT: Positive Integer
freq_for_responsiveness: Until freq_for_responsiveness, Up Threshold considered for sampling load is up_threshold_at_min_freq. Also during the part where CPU is at maximum load frequency, governor need to find the optimal frequency as the next frequency - which should not trigger up_threshold in the next sampling. When such a frequency_next is found to be a) less than freq_for_responsiveness b) will not trigger down_threshold in the next sample, then the optimal frequency is set to freq_for_responsiveness.
up_threshold_at_min_freq: This threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. Again, during calculation of optimal frequency which should not trigger up policy, down threshold to consider is difference between up_threshold_at_min_freq and down_differential
io_is_busy: Setting to 1 causes treating i/o wait time as CPU busy time. I/O busy is just an indication that CPU is performance critical, and system is not actually idle. IO wait time is excluded from the CPU idle time value is 1.
UNIT: Boolean 1 or 0
max_cpu_lock: If set to zero, hotplugs in and out second core when appropriate. Otherwise specifies no of cores to be considered for hotplugging. Leave it as default 0.
UNIT: Integer 0/1/2
hotplug_lock: Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock for a non-zero value. Leave it as 0.
UNIT: Integer 0/1/2
cpu_up_freq: Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
cpu_down_freq: Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
up_nr_cpus: Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.
UNIT: Integer 1/2
dvfs_debug: Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.
UNIT: Boolean 1 or 0

pegasusq.html"]http://www.androidiani.com/forum/modding-huawei-ascend-p1/280978-governor-pegasusq.html

Informations about I/O Schedulers

Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

V(R)
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.

FIFO
It is an acronym for First In, First Out, which is an abstraction related to ways of organizing and manipulation of data relative to time and prioritization. This expression describes the principle of a queue processing technique or servicing conflicting demands by ordering process by first-come, first-served (FCFS) behaviour. FCFS is also the jargon term for the FIFO operating system scheduling algorithm, which gives every process CPU time in the order they come. Disk controllers can use the FIFO as a disk scheduling algorithm to determine the order to service disk I/O requests.

Zen
The zen I/O scheduler is basically based off of no-op with some exceptions. It uses deadlines, prioritizes synchronous requests over asynchronous requests, and does no sorting or merging.
It's similar to SIO, but closer to no-op, whereas SIO is closer to deadline without sorting or merging (on SIO, writes can starve read requests/writes are prioritized over writes, it uses its own former/latter_request functions where zen just uses the elevator ones). I think dispatching is also slightly different on SIO, everything on zen is just back-inserted closer to FCFS (but still not pure FCFS like FIFO).(Thanks to the member Bbedward on rootzwiki.com http://rootzwiki.com/topic/35781-kernel-ada-4142-zenseries-vx-zenx-walking-tall/page__st__750)

Row
The ROW scheduling algorithm will be used in mobile devices as default block layer IO scheduling algorithm. ROW stands for "READ Over WRITE" which is the main requests dispatch policy of this algorithm.
The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have AS much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.(Thanks to Tatyana Brokhman.http://comments.gmane.org/gmane.linux.ports.arm.msm/2911)

I/O Schedulers tunables explanations​

Deadline, SIO and Zen :
fifo_batch: This determines the number of reads or writes to issue in a single batch. The default is 16. Setting this to a higher value may result in better throughput, but will also increase latency.
front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).
read_expire: This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to 500 ms (half a second).
write_expire: This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to 5000 ms (five seconds).
writes_starved: This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s02.html

CFQ
back_seek_max: Backward seeks are typically bad for performance, as they can incur greater delays in repositioning the heads than forward seeks do. However, CFQ will still perform them, if they are small enough. This tunable controls the maximum distance in KB the I/O scheduler will allow backward seeks. The default is 16 KB.
back_seek_penalty: Because of the inefficiency of backward seeks, a penalty is associated with each one. The penalty is a multiplier; for example, consider a disk head position at 1024KB. Assume there are two requests in the queue, one at 1008KB and another at 1040KB. The two requests are equidistant from the current head position. However, after applying the back seek penalty (default: 2), the request at the later position on disk is now twice as close as the earlier request. Thus, the head will move forward.
fifo_expire_async: This tunable controls how long an async (buffered write) request can go unserviced. After the expiration time (in milliseconds), a single starved async request will be moved to the dispatch list. The default is 250 ms.
fifo_expire_sync: This is the same as the fifo_expire_async tunable, for for synchronous (read and O_DIRECT write) requests. The default is 125 ms.
group_idle: When set, CFQ will idle on the last process issuing I/O in a cgroup. This should be set to 1 when using proportional weight I/O cgroups and setting slice_idle to 0 (typically done on fast storage).
group_isolation: If group isolation is enabled (set to 1), it provides a stronger isolation between groups at the expense of throughput. Generally speaking, if group isolation is disabled, fairness is provided for sequential workloads only. Enabling group isolation provides fairness for both sequential and random workloads. The default value is 0 (disabled). Refer to Documentation/cgroups/blkio-controller.txt for further information.
low_latency: When low latency is enabled (set to 1), CFQ attempts to provide a maximum wait time of 300 ms for each process issuing I/O on a device. This favors fairness over throughput. Disabling low latency (setting it to 0) ignores target latency, allowing each process in the system to get a full time slice. Low latency is enabled by default.
quantum: The quantum controls the number of I/Os that CFQ will send to the storage at a time, essentially limiting the device queue depth. By default, this is set to 8. The storage may support much deeper queue depths, but increasing quantum will also have a negative impact on latency, especially in the presence of large sequential write workloads.
slice_async: This tunable controls the time slice allotted to each process issuing asynchronous (buffered write) I/O. By default it is set to 40 ms.
slice_idle: This specifies how long CFQ should idle while waiting for further requests. The default value in Red Hat Enterprise Linux 6.1 and earlier is 8 ms. In Red Hat Enterprise Linux 6.2 and later, the default value is 0. The zero value improves the throughput of external RAID storage by removing all idling at the queue and service tree level. However, a zero value can degrade throughput on internal non-RAID storage, because it increases the overall number of seeks. For non-RAID storage, we recommend a slice_idle value that is greater than 0.
slice_sync: This tunable dictates the time slice allotted to a process issuing synchronous (read or direct write) I/O. The default is 100 ms.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04.html#id3044417

BFQ
timeout_sync, timeout_async: the maximum amount of disk time that can be given to a task once it has been selected for service, respectively for synchronous and asynchronous queues. It allows the user to specify a maximum slice length to put an upper bound to the latencies imposed by the scheduler.
max_budget: the maximum amount of service, measured in disk sectors, that can be provided to a queue once it is selected (of course within the limits of the above timeouts). According to what we said in the description of the algoritm, larger values increase the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. The price is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning: BFQ tries to estimate it as the maximum number of sectors that can be served during timeout_sync.
max_budget_async_rq: in addition to the max_budget, limit, async queues are served for a maximum number of requests, after that a new queue is selected.
low_latency: if equal to 1 (default value), interactive and soft real-time applications are privileged and experience a lower latency.
http://algo.ing.unimo.it/people/paolo/disk_sched/description.php


Row:
hp_read_quantum: dispatch quantum for the high priority READ queue
rp_read_quantum: dispatch quantum for the regular priority READ queue
hp_swrite_quantum: dispatch quantum for the high priority Synchronous WRITE queue
rp_swrite_quantum: dispatch quantum for the regular priority Synchronous WRITE queue
rp_write_quantum: dispatch quantum for the regular priority WRITE queue
lp_read_quantum: dispatch quantum for the low priority READ queue
lp_swrite_quantum: dispatch quantum for the low priority Synchronous WRITE queue
read_idle: how long to idle on read queue in Msec (in case idling is enabled on that queue).
read_idle_freq: frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests

(http://lwn.net/Articles/509829/)
 
Last edited:

TBayTom

Senior Member
Mar 17, 2011
575
120
Orlando
With 4G LTE running most of the day...

erapu3a2.jpg


duje4ere.jpg


a2a8e3ad.jpg


Ondemand/bfq
Oc 1674 min 384
Touch Boosters 1242 & 918
Screen Off 384
Voltages lowered 50 or 100 across the board

ARIEL 2.07 ICS rom

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 
Last edited:
  • Like
Reactions: xshadowinxbc

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
Have you tried ktoonservative?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
How many minutes of asphalt 7?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

TBayTom

Senior Member
Mar 17, 2011
575
120
Orlando
Have you tried ktoonservative?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Yes, I tried ktoonservative and noop at first, but for some reason it was draining my battery pretty fast (probably 8hr battery life). That was the 9-5 build, maybe my phone just doesn't like those settings, I'm not sure.


How many minutes of asphalt 7?

About 20 mins of Asphalt 7
 

corythug

Senior Member
Aug 2, 2011
1,626
206
PA
I have my screen off at 810mhz, although I have 810mhz uv to 800mv so going any lower is a waste

Sent from my SGH-I747 using Tapatalk 2
 

thuglifesk

Senior Member
Aug 17, 2007
735
132
Toronto
Samsung Galaxy Z Fold 4
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
 

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?

Sio schedulor with Pegasusq governor and try some under voting. Screen off profile around 486. Drop the vibration strength.

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

Heisenberg420

Senior Member
Apr 28, 2011
2,286
1,015
Philadelphia
Google Pixel 6
OnePlus 11
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?

I recommend not tweaking anything. The kernel alone provides better battery life and smooth experience. Although no harm in trying different governors and io schedulers. Try ktoonservative governor for better battery life.
 
  • Like
Reactions: lee718

thuglifesk

Senior Member
Aug 17, 2007
735
132
Toronto
Samsung Galaxy Z Fold 4
Sio schedulor with Pegasusq governor and try some under voting. Screen off profile around 486. Drop the vibration strength.

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!

Thanks will try these settings... whats the different between the different schedulors and governors? sorry for the general questions.
 

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec

theraker007

Senior Member
Jul 22, 2012
569
68
Hi liltitiz! I am really interested in trying your setup but when i applied your voltages my phone restarted and I ended up with all the defaults again :(
 
  • Like
Reactions: lee718

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
Hi liltitiz! I am really interested in trying your setup but when i applied your voltages my phone restarted and I ended up with all the defaults again :(

Your phone don't handle this under voltage try these:

MHz/stock mv/my mv/-mv amount

96/925/785/-140
144/925/790/-135
192/925/800/-125
384/925/825/-100
486/925/845/-80
540/950/865/-85
594/950/875/-75
648/975/890/-85
702/975/895/-80
756/1025/950/-75
810/1025/955/-70
864/1050/970/-80
918/1050/980/-70
972/1075/985/-90
1026/1075/990/-85
1080/1125/1015/-110
1134/1125/1025/-100
1188/1150/1040/-110
1242/1150/1055/-95
1296/1175/1065/-110
1350/1175/1080/-95
1404/1185/1095/-90
1458/1185/1110/-75
1512/1200/1120/-80
1674/1200/1125/-75
1728/1250/1145/-105
1809/1275/1185/-90
1890/1300/1215/-85
1998/1325/1240/-85
2106-1350-1300

For the steps 1809 to 2106 dont under volt too much. From these voltage test the limit of your phone

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 
Last edited:

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
The new setting I'm trying right now looks badass. I'll post the results later tonight!

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

endlessevo

Senior Member
May 19, 2008
70
20
Running Parinoid Android v2.1 with Ktoonsez's KT747 9/13 Jelly Bean kernel
I/O Scheduler = noop
Governor = ktoonservative

Mhz ______ mV _____ Difference from stock
1512______1075_____-125
1458______1050_____-135
1404______1040_____-145
1350______1025_____-150
1296______1015_____-160
1242______1000_____-150
1188______0985_____-165
1134______0970_____-155
1080______0955_____-170
1026______0925_____-150
0972______0910_____-165
0918______0900_____-150
0864______0890_____-160
0810______0875_____-150
0756______0855_____-170
0702______0825_____-150
0648______0815_____-160
0594______0800_____-150
0540______0785_____-165
0486______0775_____-150
0384______0770_____-155
0192______0755_____-170
0144______0745_____-180
0096______0745_____-180
 

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
Sorry if I didn't post anything yet but my battery las longer than expected!

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

liltitiz

Senior Member
Aug 15, 2012
1,037
611
Québec
So here it is!
View attachment 1330080
View attachment 1330081

96Mhz-2106Mhz
Screen off profile: 486MHz
Scheduler: SIO
Governor: Pegasusq
Kernel: kt747 9/13
Rom: AOKP 9/13


pegasusQ settings:

cpu down rate:20
cpu up rate:10
down differential:10

dvfs debug:0
freq for responsiveness:500000
freq step:9

hotplug 1_1:500000
hotplug 2_0:200000
hotplug 2_1:500000

ignore nice load:0
io is busy:0
max cpu clock:0

min cpu lock:0
sampling down factor:4
sampling rate:10000

sampling rate min:10000
up nr cpus:1
up treshold:90
up treshold at min freq:70

Under voltage values:

2106MHz - 1250mv
1998MHz - 1190mv
1890MHz - 1165mv
1809MHz - 1135mv
1728 MHz - 1090mV
1674 MHz - 1075mV
1512 MHz - 1065mV
1458 MHz - 1050mV
1404 MHz - 1040mV
1350 MHz - 1025mV
1296 MHz - 1015mV
1242 MHz - 1000mV
1188 MHz - 990mV
1134 MHz - 970mV
1080 MHz - 950mV
1026 MHz - 930mV
972 MHz - 910mV
918 MHz - 890mV
864 MHz - 875mV
810 MHz - 860mV
756 MHz - 845mV
702 MHz - 830mV
648 MHz - 815mV
594 MHz - 800mV
540 MHz - 790mV
486 MHz - 780mV
384 MHz - 770mV
192 MHz - 760mV
144 MHz - 750mV
96 MHz - 740mV

Give these a try! Worth it :)

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, sio, pegasusq, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 20
    4ff7d2fbb181f.png

    It looks like this thread is starting to be way more popular than i expected when I created it! I decided to add useful OP to it.


    Here is a list of a few things to know about how I want this thread to be:


    • First of all, everybody is more than welcome to share settings, knowledge or any useful informations that could help someone. XDA is all about helping each other.
    • No Question is too stupid. Feel free to ask anything that is related to the kernel. I specified KT747 in the title because this is what I personally use but any adjustement made to governors, schedulers and undervolting will work with different kernels that allow you to adjust those settings. So even if you don't use KT747, you're welcome to post here.
    • Before posting in this thread, read the entire OP and second post with useful links and informations.
    • Finally, be respectful and have fun!

    How to share settings:
    - Begin by telling what is your rom, the date or name of the release, jellybean or ics, AOSP or touchwiz, 4.1.2 or 4.2.1 and also specify which release of KT747 you are using or if you are using another kernel.
    - Let us know your general settings: Min/Max frequencies, screen off profile(Mhz and/or governor) and vibration strength.
    - Then share with us what governor and I/O scheduler you are using and if you made any adjustements to them.
    - If you share adjustements you made on governors or schedulers, you can take screenshots or just write which tunables you change and what values you assigned to it.
    - If you share undervolting settings, to avoid huge post with a lot of screenshots,we will do it differently: If you substracted the same amount of mV to every steps, just say how much. If you tweaked every steps separetly, you can type each voltages or you just make sure you have a backup of your settings, go into /sdcard/KTweaker/, copy the lines coresponding to the voltages and share it this way:
    Voltage(from 2106 to 96 MHz):
    1250 1225 1200 1175 1150 1125 1100 1085 1065 1045 1025 1005 985 965 945 925 905 890 875 860 845 830 815 800 790 780 770 760 750 745.
    - To share your KTweaker backup file (/sdcard/KTweaker/). Specify if it is set on boot or not and if it has custom voltages. If you have custom undervoltage setting you better make a backup that is not set on boot or set on boot after 30 seconds. So if some device doesn't take your undervolt values they won't be stock in a bootloop.



    Finally, Thanks to Ktoonsez for his amazing kernel that you can find here: http://xdaforums.com/showthread.php?t=1756776
    You can Donate to Ktoonsez here: http://xdaforums.com/donatetome.php?u=4325945
    20
    This is what I have got today with your settings... I have done a full charge on the phone yet. I've been charging it when it was at 40% or 50% so tonight will be the first time I do that. Everything's the same pretty much, used your settings on Ktweaker. Sync is off. Wifi and mobile data have been on most, if not all, of the day. Started using less of it around 5-9 pm. Mediocre battery life I'd say with the screen time I got. Don't know how I can make it better. Suggestions?

    Whoa! i'm stoked somebody tried my setup! It's been awhile since i posted that and my setup has probably changed very drastically from that file.

    I don't have wifi like i did at school so i'm not as active on XDA anymore. but you guys may have just inspired me to write a thorough post about cool stuff to tweak and play with. I haven't posted in this thread in awhile so i haven't been keeping up with what's going on that much but i wanted to share the fun things i've been playing with.

    Mr. jacqstrap this will be a long post but i hope you can try this out and see if it works for you. There's a TL;DR at the end so you can use that if you don't want to read the step by step stuff. Oh and for a day on wifi and data you had pretty decent battery life. i've found variables like location tremendously affect cell reception and battery life. like when i was in kansas on their 4g as opposed to the California Bay Area 4g(which is incredibly bogged down by everyone in the silicon valley) I got fantastic battery life in kansas under same, if not more usage. point is battery life is pretty hard to compare and quantify across devices and locations and usage patterns.


    ok here goes.

    first things first.
    cpu0 = first cpu, the one ktweaker governor tweaks affect.
    cpu1 = second cpu, the one you don't get to adjust with ktweaker.

    OK so you may or may not have known but when you change a governor or any cpu tweaks you are only affecting one core. Strange right? Not necessarily, the second core uses interactive as it's stock governor. this allows the cpu to scale up to 15xxmhz, or whatever the max is, really rapidly. this helps defeat lots and lots of lag. if you write to the settings file to use ktoonservative as the cpu1 governor instead of interactive you will see the lag i am talking about almost right away.

    So what are we to do? if we de-tune cpu0 with very high thresholds and a high sampling rate we can almost effectively make a single core phone. since cpu1 will most likely be running at 1512 most of the time to take the load that could be distributed to cpu0. When i had done all my tuning in the past i was under the impression that both cores ran at the same frequecny, this is not the case. cup0 can be at 81mhz and cpu1 can be at 1512mhz.


    You're probably asking which is better? to detune cpu0 with ktweaker which forces almost all the load onto cpu1? or is it better to underclock both and try and distribute the load between the two?


    If you want a quick rundown of my setup i have basically a lower frequency dual core that runs pretty close to the same frequency to each other.


    Well this is where i need help from you guys, since you are so good at testing. I've been running a very unique setup, which i'll write about in a moment.

    I used Script Manager - SManager from the play store and wrote my own script file to write my settings to the files to change cpu1's values.
    I also used PerfMon - Performance Monitor from the play store to monitor what both cpu's were doing during my testing and stuff.


    my current setup includes

    cpu0 = 1296mhz - ktoonservative governor (plus all the threshold and voltage tweaks which will be posted)
    cpu1 = 1080mhz - asswax governor

    OK now for the instructions for how to fool around with cpu1



    Ok so if you use a hotplugging governor you actually can't access the cpu1 folder if the governor has turned the core off and hot plugged it out. for me when I wanted to adjust cpu1's settings i would start a bench marking app to force a load onto both cpu's. This prevents the folder from disappearing.

    to fool with cpu1 for testing you can go here, assuming it's not turned off by hotplugging.

    /sys/devices/system/cpu/cpu1/cpufreq/

    using an appropriate root explorer or terminal or ADB you can write to these files and change them to the values you want to test.

    for example, here's what my script runs



    echo 1080000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq

    and

    echo asswax > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor


    this only changes the governor and max frequency for cpu1.

    You can play around with things and get a feel for how much lag you desire.

    ok anyways, so lets say you've played with your settings for awhile but then you realize at some point you will reboot and loose all your settings when KTweaker starts up. ok. so to get around this I wrote my script file and used SManager to run it at boot so it preserves settings across boots.



    You can write your own script, or use mine and change the values(assuming you can change them to the correct values). scripts are really pretty simple.

    Here's my script https://www.dropbox.com/s/fpzrxfzry5s6cl3/1080mhz-asswax

    NOW! before you assume everything is correct and set your phone to boot a script hoping everything is right, you need to test it first!

    go download Terminal Emulator for the play store and run the sh command on the script. This will run the script once, and if you somehow make your phone unstable and it reboots all will be well.

    so give the terminal emulator superuser permission,

    su

    ok after that run

    sh /sdcard/path/to/your/script/whatever-you-named-the-script

    when i run my script i use

    sh /sdcard/1080mhz-asswax


    it's helpful to have PerfMon running so you can see the change happen.


    Ok so now assuming your script works and does what it should(you can always check it with a root explorere) put your script on your SD card and point SManager to it and tell it to run on boot.

    SManager can be kind of tricky at first but it is definitely usable, let me know if you have any trouble with this.

    NOW

    Here's where things get tricky! ktweaker will overwrite your script settings if there is any delay set up on ktweaker. you have to go to ktweaker and tell it to set options on boot. This will prevent ktweaker from overwriting whatever your script does since SManager runs a slight bit later than ktweaker.


    Ok guys, i've spent a lot of time writing this, and even longer testing this out, please guys give this a try. it took me quite awhile to figure out a surefire method to make my settings stick. Please let me know how it works out for you guys!



    TL;DR


    1. cpu1 has some values that aren't affected by ktweaker
    2. you can change the values using root explorer, terminal emulator, or scripts
    3. here's my script, feel free to make your own or to edit mine https://www.dropbox.com/s/fpzrxfzry5s6cl3/1080mhz-asswax
    3a. Here's my ktweaker file (the voltages will likely crash you phone as i have spent like hours tuning them to fit my phone) https://www.dropbox.com/s/sk78has35kf787a/BaconatorXVI's 1296 ktoonservative
    4. run the script using sh in terminal emulator
    5. once it all works use SManager to run script at boot, also run ktweaker at boot
    6. ????
    7. Profit
    8. Tell BaconatorXVI about your battery life, if it improves or not!


    please try this out :laugh:
    begging-cat.jpg
    12
    Useful links and informations

    Useful links and informations.

    Informations about Governors:​

    The following infos were found here:
    http://xdaforums.com/showthread.php?t=1369817
    http://xdaforums.com/showthread.php?p=28647926
    http://xdaforums.com/showthread.php?t=1369817

    Ondemand:
    Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings.

    Conservative:
    A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency.

    Interactive:
    Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations.

    Intellidemand:
    To sum up, 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.

    Lagfree:
    Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.

    Userspace:
    Instead of automatically determining frequencies, lets user set frequencies.

    Powersave:
    Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).

    Performance:
    Sets min frequency as max frequency. Use this while benchmarking!

    Scary:
    A new governor wrote based on conservative with some smartass features

    Wheatley:
    Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
    target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
    allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups.

    Pegasusq:
    The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
    Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values ​​arranged.

    MSM DCVS:
    a very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements.

    Abyssplug governor:
    It is a modified Hotplug Governor: The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.

    SLP governor:
    It is a mix of pegasusq and ondemand


    Governor tunables explanations​

    OnDemand, Conservative, Ktoonservative, Adaptive, Intellidemand:
    sampling_rate:Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
    up_threshold: Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
    powersave_bias: Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
    sampling_down_factor: In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
    down_differential: This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
    freq_step: Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.

    SmartassV2 & AssWax
    awake_ideal_freq: The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
    sleep_ideal_freq: The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
    up_rate_us: The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
    down_rate_us: The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
    max_cpu_load: Same as up_threshold in other governors.
    min_cpu_load: Same as down_threshold in other governors.
    ramp_down_step: Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
    ramp_up_step: Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
    sleep_wakeup_freq: The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.

    Interactive
    hispeed_freq: Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
    go_hispeed_load: Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
    min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
    timer_rate:
    The sample rate of the timer used to increase frequency.


    PegasusQ:
    cpu_up_rate: No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.
    UNIT: Positive Integer
    cpu_down_rate: No of samples to evaluate load to scale CPU Down. After CPU_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.
    UNIT: Positive Integer
    hotplug_freq_1_1: Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and run queue length is greater than hotplug_rq_1_1) Hotplug IN Second Core. Higher value correpsonds to delay in turning on second core.
    UNIT: Kilo Hertz
    hotplug_freq_2_0: Down threshold frequency to turn second core Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and run queue length is less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core. Lower value correpsonds to delay in turning off second core.
    UNIT: Kilo Hertz
    hotplug_rq_1_1: Threshold run queue length for second core to turn on.
    UNIT: Positive Integer
    hotplug_rq_2_0: Threshold run queue length for second core to turn off.
    UNIT: Positive Integer
    freq_for_responsiveness: Until freq_for_responsiveness, Up Threshold considered for sampling load is up_threshold_at_min_freq. Also during the part where CPU is at maximum load frequency, governor need to find the optimal frequency as the next frequency - which should not trigger up_threshold in the next sampling. When such a frequency_next is found to be a) less than freq_for_responsiveness b) will not trigger down_threshold in the next sample, then the optimal frequency is set to freq_for_responsiveness.
    up_threshold_at_min_freq: This threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. Again, during calculation of optimal frequency which should not trigger up policy, down threshold to consider is difference between up_threshold_at_min_freq and down_differential
    io_is_busy: Setting to 1 causes treating i/o wait time as CPU busy time. I/O busy is just an indication that CPU is performance critical, and system is not actually idle. IO wait time is excluded from the CPU idle time value is 1.
    UNIT: Boolean 1 or 0
    max_cpu_lock: If set to zero, hotplugs in and out second core when appropriate. Otherwise specifies no of cores to be considered for hotplugging. Leave it as default 0.
    UNIT: Integer 0/1/2
    hotplug_lock: Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock for a non-zero value. Leave it as 0.
    UNIT: Integer 0/1/2
    cpu_up_freq: Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.
    UNIT: Kilo Hertz
    cpu_down_freq: Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.
    UNIT: Kilo Hertz
    up_nr_cpus: Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.
    UNIT: Integer 1/2
    dvfs_debug: Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.
    UNIT: Boolean 1 or 0

    pegasusq.html"]http://www.androidiani.com/forum/modding-huawei-ascend-p1/280978-governor-pegasusq.html

    Informations about I/O Schedulers

    Noop
    Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

    Deadline
    Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

    CFQ
    Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

    BFQ
    Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

    SIO
    Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

    V(R)
    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.

    FIFO
    It is an acronym for First In, First Out, which is an abstraction related to ways of organizing and manipulation of data relative to time and prioritization. This expression describes the principle of a queue processing technique or servicing conflicting demands by ordering process by first-come, first-served (FCFS) behaviour. FCFS is also the jargon term for the FIFO operating system scheduling algorithm, which gives every process CPU time in the order they come. Disk controllers can use the FIFO as a disk scheduling algorithm to determine the order to service disk I/O requests.

    Zen
    The zen I/O scheduler is basically based off of no-op with some exceptions. It uses deadlines, prioritizes synchronous requests over asynchronous requests, and does no sorting or merging.
    It's similar to SIO, but closer to no-op, whereas SIO is closer to deadline without sorting or merging (on SIO, writes can starve read requests/writes are prioritized over writes, it uses its own former/latter_request functions where zen just uses the elevator ones). I think dispatching is also slightly different on SIO, everything on zen is just back-inserted closer to FCFS (but still not pure FCFS like FIFO).(Thanks to the member Bbedward on rootzwiki.com http://rootzwiki.com/topic/35781-kernel-ada-4142-zenseries-vx-zenx-walking-tall/page__st__750)

    Row
    The ROW scheduling algorithm will be used in mobile devices as default block layer IO scheduling algorithm. ROW stands for "READ Over WRITE" which is the main requests dispatch policy of this algorithm.
    The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have AS much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
    The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.(Thanks to Tatyana Brokhman.http://comments.gmane.org/gmane.linux.ports.arm.msm/2911)

    I/O Schedulers tunables explanations​

    Deadline, SIO and Zen :
    fifo_batch: This determines the number of reads or writes to issue in a single batch. The default is 16. Setting this to a higher value may result in better throughput, but will also increase latency.
    front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).
    read_expire: This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to 500 ms (half a second).
    write_expire: This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to 5000 ms (five seconds).
    writes_starved: This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
    https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04s02.html

    CFQ
    back_seek_max: Backward seeks are typically bad for performance, as they can incur greater delays in repositioning the heads than forward seeks do. However, CFQ will still perform them, if they are small enough. This tunable controls the maximum distance in KB the I/O scheduler will allow backward seeks. The default is 16 KB.
    back_seek_penalty: Because of the inefficiency of backward seeks, a penalty is associated with each one. The penalty is a multiplier; for example, consider a disk head position at 1024KB. Assume there are two requests in the queue, one at 1008KB and another at 1040KB. The two requests are equidistant from the current head position. However, after applying the back seek penalty (default: 2), the request at the later position on disk is now twice as close as the earlier request. Thus, the head will move forward.
    fifo_expire_async: This tunable controls how long an async (buffered write) request can go unserviced. After the expiration time (in milliseconds), a single starved async request will be moved to the dispatch list. The default is 250 ms.
    fifo_expire_sync: This is the same as the fifo_expire_async tunable, for for synchronous (read and O_DIRECT write) requests. The default is 125 ms.
    group_idle: When set, CFQ will idle on the last process issuing I/O in a cgroup. This should be set to 1 when using proportional weight I/O cgroups and setting slice_idle to 0 (typically done on fast storage).
    group_isolation: If group isolation is enabled (set to 1), it provides a stronger isolation between groups at the expense of throughput. Generally speaking, if group isolation is disabled, fairness is provided for sequential workloads only. Enabling group isolation provides fairness for both sequential and random workloads. The default value is 0 (disabled). Refer to Documentation/cgroups/blkio-controller.txt for further information.
    low_latency: When low latency is enabled (set to 1), CFQ attempts to provide a maximum wait time of 300 ms for each process issuing I/O on a device. This favors fairness over throughput. Disabling low latency (setting it to 0) ignores target latency, allowing each process in the system to get a full time slice. Low latency is enabled by default.
    quantum: The quantum controls the number of I/Os that CFQ will send to the storage at a time, essentially limiting the device queue depth. By default, this is set to 8. The storage may support much deeper queue depths, but increasing quantum will also have a negative impact on latency, especially in the presence of large sequential write workloads.
    slice_async: This tunable controls the time slice allotted to each process issuing asynchronous (buffered write) I/O. By default it is set to 40 ms.
    slice_idle: This specifies how long CFQ should idle while waiting for further requests. The default value in Red Hat Enterprise Linux 6.1 and earlier is 8 ms. In Red Hat Enterprise Linux 6.2 and later, the default value is 0. The zero value improves the throughput of external RAID storage by removing all idling at the queue and service tree level. However, a zero value can degrade throughput on internal non-RAID storage, because it increases the overall number of seeks. For non-RAID storage, we recommend a slice_idle value that is greater than 0.
    slice_sync: This tunable dictates the time slice allotted to a process issuing synchronous (read or direct write) I/O. The default is 100 ms.
    https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s04.html#id3044417

    BFQ
    timeout_sync, timeout_async: the maximum amount of disk time that can be given to a task once it has been selected for service, respectively for synchronous and asynchronous queues. It allows the user to specify a maximum slice length to put an upper bound to the latencies imposed by the scheduler.
    max_budget: the maximum amount of service, measured in disk sectors, that can be provided to a queue once it is selected (of course within the limits of the above timeouts). According to what we said in the description of the algoritm, larger values increase the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. The price is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning: BFQ tries to estimate it as the maximum number of sectors that can be served during timeout_sync.
    max_budget_async_rq: in addition to the max_budget, limit, async queues are served for a maximum number of requests, after that a new queue is selected.
    low_latency: if equal to 1 (default value), interactive and soft real-time applications are privileged and experience a lower latency.
    http://algo.ing.unimo.it/people/paolo/disk_sched/description.php


    Row:
    hp_read_quantum: dispatch quantum for the high priority READ queue
    rp_read_quantum: dispatch quantum for the regular priority READ queue
    hp_swrite_quantum: dispatch quantum for the high priority Synchronous WRITE queue
    rp_swrite_quantum: dispatch quantum for the regular priority Synchronous WRITE queue
    rp_write_quantum: dispatch quantum for the regular priority WRITE queue
    lp_read_quantum: dispatch quantum for the low priority READ queue
    lp_swrite_quantum: dispatch quantum for the low priority Synchronous WRITE queue
    read_idle: how long to idle on read queue in Msec (in case idling is enabled on that queue).
    read_idle_freq: frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests

    (http://lwn.net/Articles/509829/)
    9
    So here it is!
    View attachment 1330080
    View attachment 1330081

    96Mhz-2106Mhz
    Screen off profile: 486MHz
    Scheduler: SIO
    Governor: Pegasusq
    Kernel: kt747 9/13
    Rom: AOKP 9/13


    pegasusQ settings:

    cpu down rate:20
    cpu up rate:10
    down differential:10

    dvfs debug:0
    freq for responsiveness:500000
    freq step:9

    hotplug 1_1:500000
    hotplug 2_0:200000
    hotplug 2_1:500000

    ignore nice load:0
    io is busy:0
    max cpu clock:0

    min cpu lock:0
    sampling down factor:4
    sampling rate:10000

    sampling rate min:10000
    up nr cpus:1
    up treshold:90
    up treshold at min freq:70

    Under voltage values:

    2106MHz - 1250mv
    1998MHz - 1190mv
    1890MHz - 1165mv
    1809MHz - 1135mv
    1728 MHz - 1090mV
    1674 MHz - 1075mV
    1512 MHz - 1065mV
    1458 MHz - 1050mV
    1404 MHz - 1040mV
    1350 MHz - 1025mV
    1296 MHz - 1015mV
    1242 MHz - 1000mV
    1188 MHz - 990mV
    1134 MHz - 970mV
    1080 MHz - 950mV
    1026 MHz - 930mV
    972 MHz - 910mV
    918 MHz - 890mV
    864 MHz - 875mV
    810 MHz - 860mV
    756 MHz - 845mV
    702 MHz - 830mV
    648 MHz - 815mV
    594 MHz - 800mV
    540 MHz - 790mV
    486 MHz - 780mV
    384 MHz - 770mV
    192 MHz - 760mV
    144 MHz - 750mV
    96 MHz - 740mV

    Give these a try! Worth it :)

    Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, sio, pegasusq, undervolted, 3150mAh battery.
    Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
    8
    Re: KT747 KTweaker: share and discuss your setting

    liltitiz,

    I've read the entire thread twice and there has been a lot of debate regarding settings for up/down thresholds. I was having latency and mw 86 suggested I increase the up/down threshold values. How does lowering then help reduce latency and increase battery life? Your answer will help a lot of us intermediate users.

    Sent from my SPH-L710 using Tapatalk 2

    Up threshold is the amount of usage(as a % of the max CPU usage) your CPU will need to reach before it steps to a higher frequencies. So the lower you set it, the better performance you'll get because your CPU will scale up faster for less usage. Set it too low and your CPU will scale up uselessly and eat more battery, set it too high and your phone may overheat and start being laggy. So set it with what works best for you.

    Down threshold is basically the same, except it is the amount of usage your CPU need to reach before it scales down to a lower frequency once is done processing the task. The lower you set it, better performance but also eats up more battery since your CPU won't scale down appropriately according to the task left to process. Set it too high and you CPU will scale down too soon and your CPU will take more time to process a task that would've take a fraction of the time at a higher frequency. So it will also eat more battery, may overheat and cause laggyness.

    Up and down hotplugging thresholds work the same as regular threshold, but they set the amount of usage your CPU needs to reach before it turns on or off the second core.

    Set the up hot plugging threshold higher than your up threshold and your CPU will reach your max freq before turning the second core on.

    Set the down hot plug threshold lower than your down threshold and your CPU will reach the lower freq before turning off the second core.

    Sent from my SGH-I747 using xda app-developers app