Database Info

BatteryStatus CPU Scaling: How-to and purpose.

I've been staring at BatteryStatus' CPU Scaling function wondering what good it does if I use it... and how do I use it if I decide that it was useful. I'm sure some users here are wondering the same thing, especially on our low-powered Wizards. Can someone lay it thick for us CPU-shy users?

The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)

Sweet
starkwong; said:
The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)
Click to expand...
Click to collapse
Awesome! Something usable when my phone's bluetooth connected to my car.
Now, how does one set up these options to take advantage of this function?

It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.

shantzg001 said:
It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.
Click to expand...
Click to collapse
Well said !
Dont get me wrong but pls search before shooting off questions.
Plz read the forum,you'll find all the answers to your question in here,these kind of questions have been asked hundreds of times in various threads or shud have posted in the appropriate thread from you downloaded your present rom TNT 5.0. Or hit the 'Search' button at the top with your specific word to locate,you'll be amazed.There's no need to start a new thread for this.

Just remember...
More Mhz translates into less power efficency.
ie.
195 mhz (stock speed) = Regular Baterry consuption
240 mhz (overclocked speed) = Over Regular Baterry consuption
260 mhz (overclocked speed) = High Baterry consuption
280 mhz (overclocked speed) = you got the idea
Also remember that when increasing the processor Speed may cause your system to hang or not wakeup if you are using a very low frequency.
Best regards.

[DEV ONLY] i9003 overclock module [need help from devs]

hello guys so i was looking at this project for Motorola Droid X:
http://code.google.com/p/milestone-overclock/
since Droid X has similar OMAP3630 chipset i thought we could try it out for this device...
if it has already been tried out by u guys then sorry for dupe post
anyways the sources available (milestone-overclock-module-1.4.8.tar.gz) were not directly compatible with the i9003 kernel sources (GB_CHN_UPDATE1) so i have modified it slightly.... and now the module gets compiled and it gets loaded (by insmod)... the sysfs and proc interface is active... even the app (MilestoneOverclock148.apk) detects the module correctly... but the changes dont work...
i invite all devs to help out with this...
modified sources are posted here:
https://github.com/DooMLoRD/i9003-overclock
noobs kindly dont spam this thread....
P.S.: Droid X has got overclock upto 1.4GHz with help of this so i am sure we can try little more overclock than 1.1GHz

If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?

previously i was also having milestone A853 and by the overclock module it can be overclocked to 1.2 ghz

XDA_Bam said:
If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?
Click to expand...
Click to collapse
Yes I know the changes in diff omap kernel sources... Spent a few hrs today comparing milestone/droid x and i9003 kernel sources to get this module complied and loading...
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
As for ur other two questions I posted this earlier in the other thread
DooMLoRD said:
Not sure... These omap chips seem to have only 4 bins (300/600/800/1000)... We are currently making the 1000 MHz bin run at 1100mhz... I am not sure if we can add extra bins... I tried adding a lower 125MHz bin, it was shown by setcpu but the device never really went below 300mhz... May be we need to investigate it further...
Sent from my R800i using XDA App
Click to expand...
Click to collapse
P.S.: the chip on this phone is OMAP3630
Sent from my R800i using XDA App

DooMLoRD said:
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
Click to expand...
Click to collapse
OK, so the overclock is working. Nice Concerning the mpurate, have a look here. The author is working at TI, so I expect him to be familiar with the code. However, that does not mean we can't use the conversion factor for overclock. It's just not "clean".
DooMLoRD said:
P.S.: the chip on this phone is OMAP3630
Click to expand...
Click to collapse
Yep, you're right. Got that wrong
---------- Post added at 10:50 PM ---------- Previous post was at 10:41 PM ----------
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.

http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out

XDA_Bam said:
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.
Click to expand...
Click to collapse
That looks very much like the sysfs interface we added for VDD control on QSD8250/MSM7X30... Should work I think...
Sent from my R800i using XDA App
akashsgpgi said:
http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out
Click to expand...
Click to collapse
U should be BANNED for spamming.... The link u posted is already there in the second line of the main post...
READ!!!!
Sent from my R800i using XDA App

I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.

XDA_Bam said:
I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.
Click to expand...
Click to collapse
so wht cpu freq table are u using exactly?
wht i think is we should concentrate on this (atleast for now):
just keep the 4 bins as is (300, 600, 800, 1000)
then try n get the access to these via sysfs (or proc)
see if we can modify them via that interface, say change 1000 to 1100 or change 800 to 900
and then do tests if these work...
if possible make a sysfs (or proc) interface for VDD (voltage control) too...
have u pushed the testing changes... i am working on same thing here... might help to speed things up...

I am currently testing on the master branch, so the branch is "wrong", but this is the commit:
Sysfs interface
Because only underclock works as of now, I am tested setting
Code:
if (mpurate < 2000)
but that didn't help. Now I will define 1100 and 1200 MHz steps in board-latona.c and cpufreq34xx.c to see if this helps.
EDIT: Nope, that didn't solve it. CPU does not run at 1100. Not even 900. Stays at 1000 in both cases. 800 can be forced...

some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address

I just thought this might be helpful since Optimus black has the same hardware.

joelmonty said:
I just thought this might be helpful since Optimus black has the same hardware.
Click to expand...
Click to collapse
its the same module dude...
these are all based on milestone-overclock module

DooMLoRD said:
some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address
Click to expand...
Click to collapse
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.

XDA_Bam said:
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.
Click to expand...
Click to collapse
read the sources of the module it explains why we need to look at those values...

DooMLoRD said:
read the sources of the module it explains why we need to look at those values...
Click to expand...
Click to collapse
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good

XDA_Bam said:
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good
Click to expand...
Click to collapse
yups code needs some more patching but i am sure this is the way forward for stable overclock

I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.

XDA_Bam said:
I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.
Click to expand...
Click to collapse
this is the same problem as with other overclocks i was playing with...
the cpufreq table doesnt get updated... only the module based way seems to change that table...
anyways we will have to investigate this further...
oh btw i have found patch to overclock GPU...

DooMLoRD said:
oh btw i have found patch to overclock GPU...
Click to expand...
Click to collapse
Nice. Hehe

[REF][GUIDE]Xperia M2 CPU Governors,Hotplugging drivers,I/O Schedulers,GPU governors

What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors for the Xperia M2
NOTE:not all govenors listed will be available for every rom or every kernel
1) Ondemand
2) Interactive
3) Intellidemand
4) Userspace
5) Powersave
6) Performance
1) 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. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) 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. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) 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. Why?????Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive 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 between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
3) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
4) Userspace:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
5) Powersave
Powersave governor locks the CPU frequency at the lowest frequency set by the user.Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
6) Performance
The performance governor locks the phone's CPU at maximum frequency(Used for benchmarking)
GOVERNOR TWEAKS
PARAMETERS & TWEAKS:
1.ONDEMAND
[ PARAMETERS ]
i) 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.
ii) 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.
iii) 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.
iv) 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.
v) 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.
vi) 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.
[ SAMPLE TWEAKS ]
i) For battery:-
To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.
up_threshold : 95
sampling_rate : 120000
sampling_down_factor : 1
down_differential : 5
ii) For performance:-
To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.
up_threshold : 70
sampling_rate : 50000
sampling_down_factor : 2
down_differential : 15
2.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:-
go_hispeed_load : 95
hispeed_freq : 1000000
min_sample_time : 10000
timer_rate : 40000
For performance:-
Assuming your scaling_max_freq is equal to or above 1400 MHz
go_hispeed_load : 80
hispeed_freq : 1400000
min_sample_time : 40000
timer_rate : 20000
Additional Info:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hotplugging drivers:
mpdecision: Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
msm_hotplug: Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
intelliplug: Great balance between battery life and performance. It is also a popular hotplug driver from faux123
Hotplug tunables guide
1) msm_mpdecision
[ PARAMETERS ]
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (70)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1.
max_cpus = max cpus to be online (if you set it to 2 and min_cpus to 1 you will basically have a dualcore)
idle_freq = a value against that will be checked if a core +/- is requested.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
I/O Schedulers:
Available I/O Schedulers for the Xperia M2:
1.Deadline
2.Noop
3.SIO (Simple I/O)
4.ROW
Deadline:
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
Benefits:
- Nearly a real-time scheduler.
- Excels in reducing latency of any given single I/O
- Best scheduler for database access and queries.
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
The bottom line: A good all-round scheduler. If you want good performance
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.
Benefits:
- Serves I/O requests with least number of CPU cycles.
- Best for flash drives since there is no seeking penalty.
- Good data throughput on db systems
- Does great in benchmarks
- Is very reliable
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not the most responsive I/O scheduler
- Not very good at multitasking (especially heavy workloads)
The bottom line: Modern smartphones now use noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons).
SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between noop & deadline. No reordering or sorting of requests.
Benefits:
- It is simple and stable.
- Minimized starvation for inquiries
- Not the best scheduler for benchmarks
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives are not as good as other IO schedulers
The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.
ROW:
The ROW I/O 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 I/O 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.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
Disadvantages:
- Not great for heavy multitasking
- Slower write speeds
The bottom line: Most phones will get a nice I/O boost, however experience varies between devices.
I/O Read Ahead Cache :
If you've used a custom kernel, you probably have heard of a term called Read Ahead cache or size. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more cache means that more files can be cached, this can mean higher read and write speeds, but also this can result in more i/o latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.
Have a look at the graph below:
Recommendations:
For stability:
Use 128kB read-head value
For performance:
Use 2048kB read-head value
For any internal storage:
Use 128kB read-ahead value
For external SD cards with less than 8GB:
Use 128kB read-head value
For 16GB external SD cards:
Use 1024kB read-head value
For 32GB external SD cards:
Use 2048kB read-head value
For 64GB+ external SD cards:
Use 2048kB read-head value
What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Not all kernels allow users to change the I/O read ahead
- Performance difference varies between devices
In simple, a 1024kB read ahead should suit most devices today. 2048kB and 512kB are also good options I recommend too.
GPU Governors
MSM-Adreno: The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life. It is still a balanced governor for everyday usage.
Ondemand: Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings. This is a widely used governor in qualcomm devices.
Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
I have spent many hours compiling all of the info on CPU governors and I/O schedulers.If you want to use the descriptions and info in your own thread, make sure to give me credit for gathering this info and also mention the others for their descriptions too. Remember that this info is for free and can be used for your own help and for others if you follow XDA rules
https://www.youtube.com/user/UmeshCahill

Thanks for the post, really interesting :good:

wow, that's really awesome sir . Nice info

iFlashed said:
Thanks for the post, really interesting :good:
Click to expand...
Click to collapse
You are welcome

FunSucker said:
wow, that's really awesome sir . Nice info
Click to expand...
Click to collapse
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes

Umesh1041 said:
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes
Click to expand...
Click to collapse
Would be great If u could suggest these tweaks to ROM developers

[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8]

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
for OOS-N, and LOS-N​
Code:
/* *** Disclaimer
* I am not responsible for bricked devices, dead SD cards, thermonuclear war,
* or you getting fired because the alarm app failed. Please do some research
* if you have any concerns about features included in this KERNEL
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
* BOOM goes the Dynamite
*/
I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.
Wanna be notified of an Update? Here is my PushBullet Channel!!
https://www.pushbullet.com/channel?tag=renderkernel
Current Features
General List:
* EAS Only
* Built with LINARO 6.x
* Updated with CAF LA.UM.5.5
* IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
* Flar Sound Control
* Wake Gestures - DT2W, S2W, and S2S
* Complete Color Calibration Thanks to @savoca
* F2FS Support
* Adrenoboost
* USB Fast Charging
I recommend Kernel Aduitor for making kernel changes
Kernel Downloads:
LOS-(EAS/HMP) Downloads
OOS-(EAS/HMP) Downloads
Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything!
* At least backup BOOT via TWRP
* Flash Zip
* Reboot
THANKS!!!!
First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:
Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!
Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today
Special Thanks!
Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1
Source Links:
https://github.com/RenderBroken/OP3-kernel
https://github.com/RenderBroken/OP3-LOS-kernel
https://github.com/RenderBroken/RenderKernel-AnyKernel2
XDA:DevDB Information
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3
Contributors
RenderBroken, Mostafa Wael, joshuous
ROM OS Version: 7.x Nougat
Version Information
Status: Testing
Created 2016-11-23
Last Updated 2017-12-15

Note:
Great write-up from @Mostafa Wael
HMP vs EAS - OxygenOS 4.1.3 stable
Right here we go!
First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here
MMX Hill Dash
HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!
True Skate
HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.
Browsing via Chrome
HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.
YouTube streaming
HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.
Overall battery life
HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.
let's get to the numbers...
App launches
[HMP]
PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size
[EAS]
PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
.
Synthetic Benchmarks
[HMP]
AnTuTu: 148,471
Geekbench 4.1.0: 1733 + 4191
Vellamo - Multicore: 3215
Vellamo - Metal: 3541
Vellamo - Chrome: 4825
[EAS]
AnTuTu: 143840
Geekbench 4.1.0: 1740 + 3290
Vellamo - Multicore: 2511
Vellamo - Metal: 3569
Vellamo - Chrome: 4350
This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....

Reserved
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it

You can't imagine how happy I am to see you here!
Sent from my ONEPLUS A3003 using Tapatalk

Download links says, N6?

ELoTRIX said:
Download links says, N6?
Click to expand...
Click to collapse
See OP#2. Sorry, still updating OP

Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app

isoladisegnata said:
Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app
Click to expand...
Click to collapse
Sorry, it will not work for CB yet. I made that clearer in OP.
I would like to offer support for it though.

TaRsY said:
You can't imagine how happy I am to see you here!
Click to expand...
Click to collapse
Me too!! I love render since lg g2 times.. Thanks Render for coming here

omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!

MBurns2 said:
Me too!! I love render since lg g2 times.. Thanks Render for coming here
Click to expand...
Click to collapse
Thanks! Glad to be here!
nadejo said:
omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!
Click to expand...
Click to collapse
I appreciate the kind words!
Everyone, please remember to provide logs in case of a reboot. I dont like to release such builds but it will happen from time to time. Especially when porting new features such as EAS.
You can get a log from
/sys/fs/pstore/console-ramoops

New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS

Great work bud
__
v7

RenderBroken said:
New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS
Click to expand...
Click to collapse
Good to see you here Buddy.. No doubts now we have one more best kernel for our beast OP3. surely gonna use permanently...
Sent from my aicp_oneplus3 using Tapatalk

Render is great just bringing another great kernel to the Oneplus 3

Look who's here.. Render.. One of the most friendly and vocal devs.. Thank you for the kernel mate.. You made opo so amazing..

Flashed looks good!
lets see for next battery cycle.

Great! EAS is really where I was hyped for! Thx for your amazing work!.
I'm going to run it 24 hours and see if there are any reboots, if there won't be ill let you know. I noted that the Cpu frequency stays quite high when there is barely any load? Is this normal?
Edit: issue with standby, couldn't get my phone on when I didn't use it for like 3-4 minutes. Had to reboot, but couldn't reproduce the problem
Issues I encountered:
1. Had an instant where my phone's screen was off for 2 minutes, i couldnt get the screen back on so i had to reboot. Yet i failed to reproduce the issue. (Logs didnt show anything)
2. CPU frequency seems to be really overkilling a task. It doesnt like to stick to 300Mhz either.
Other then that it works smooth and flawless! Even Snapchat is now using all 4 cores instead of only 2 little ones on HMP.

Hi, I know you only support OOS. Having said that, will it cause any problems if I use it over custom roms?

ROM OS Version: 2.3.x Gingerbread
Click to expand...
Click to collapse
Sorry for disturbing, but OP need some correction
Anyway, I'm impatient to test it !

[Guide] Advanced Interactive Governor Tweaks.

This guide is meant for ALL smartphones that runs the Interactive governor, copy-pasted here for better visibility. Credits goes to @soniCron for starting up the guide and @Alcolawl for further implementing it.
The Introduction
So, I tried copy-pasting the entire thread and realised it looks ugly therefore I'll rewrite it to be more simpler and straightforward.
Imagine a car with manual gears, you choose what speed is best suitable for the road conditions. Going into a curve? Best slow down. Clear straight road? Go fast so you reach the destination safely and efficiently.
That's what this guide aims to do with the Interactive governor, based on the CPU load it will choose the best and the lowest frequency to complete the task without compromising performance.
For example, if you scroll your Facebook page your CPU might clock up to the highest frequency for smooth scrolling. Now lower the frequency one step down and you may find that it's still smooth, so why isn't it choosing that instead? Don't blame the phone companies or Google, that's just a way of ensuring performance at all times. This guide will push the limits of that capability.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Click to expand...
Click to collapse
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing lags or stutters. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
Remember what was said about scrolling FB pages? This is it.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Imagine a staircase with steps of different heights. You climb these stairs better depending on the height of each steps, do you skip some steps if you can reach the next one easily? Or do you take one step at a time because they are too high?
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz (Tested by browsing FB on Chrome browser cause they're intensive enough)
Video - 787Mhz (Same thing, watch 60fps videos on different resolutions on the Youtube app to detect stutters and lags)
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
Click to expand...
Click to collapse
SO there you go, that's the gist of it. I got some smaller examples written up later so hopefully it's more understandable.
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
GlassFish (For most devices!) - High battery savings with buttery smooth interface!
HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
DrunkSauce - Supreme UI fluidity coupled with excellent active and idle battery drain. Idle Drain was consistently measured to be ~1%. And while I don't rely on SOT figures that people constantly throw around, active drain spanned from 15-20%/hr depending on usage. YMMV. And as always, flawless audio playback for you audiophiles and ARISE users out there.
Those are the ones compiled for now, please remember that these are all up to the users' preference. It will improve YOUR own SOT, not straight up 8 hours on every device. You can copy off the profiles and use your own device frequency and target loads, use an app like Kernel Auditor to help edit them. It works for stock and custom roms too.
Extra credits:
Thanks also to:
Every developer who has seen this guide, modified it, and implemented it.
All the members who contributed and argued about the inner workings of this guide, your constructive feedback is amazing and helped fine-tune future profiles.
To the poisonous and toxic trash member(s) of a certain thread for their lack of help and elitist behaviour. Their embarrassing attitude helps open our eyes to the dos and don'ts of internet manners.

This is for calculating target loads.
Let me give you an example from my Note 1:
My clock rates are (in MHz): 200, 500, 800, 1000, 1200, 1400
Their voltages are (in V): 950, 950, 1050, 1125, 1225, 1300
If I were to plot the differences in voltage, it would appear like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
From the graph, 500MHz to 800MHz has a huge difference in voltage increase compared to 1000MHz to 1200Mhz. That frequency BEFORE the huge jump is the efficient clock rate: 500MHz and 1000MHz.
So, the nominal clock rate on the other hand is the minimum frequency you can use to complete a task (such as watching videos, loading apps, page scrolling). In this case, mine are: 200MHz, 800MHz, 1000MHz
Now, we just calculate (from the first post) the minimal efficient loads for efficient clock rate and maximal efficient loads for nominal clock rate.
That means my target loads will be:
500: 60
800: 72
1000: 75
1200: 17
I skipped the calculations but this will be what it looks like from there. Someone pls do let me know if I made a mistake, as it does tend to confuse people with other devices.
Nominal clock rate: Maximal load
Efficient clock rate: Minimal load
Edit: Those are for the target loads, for the rest of the settings I'll use the profiles'.

Eh, mmight as well reserve this too

Nice looking guide, about to read

wtf,you just copy pasted in the end

Nice beginning, but half is missing, and you are referencing things that haven't been done before