Related
I take no credit of these codes. All i did is create a patch against with the leo kernel tree.
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when 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 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Click to expand...
Click to collapse
2.6.32-sched-bfs-318.patch.zip: is the patch is downloaded from official BFS site.
oc_uv_ab.patch.zip : this patch includes under volt, overclocking (upto 1.3GHz, any frequency above 1.15G is unstable on some of HD2s) and audio boost.
how does it work?
Sounds great. Maybe someone can integrate this into a kernel?
thanks for this!!
How to apply patch
I could really use the audio boost. Is there anyway you could explain how to apply the patches. Or is it possible you could apply them and post the patched kernel files? Thanks.
Would this actually have an improving effect on the touchscreen being unresponsive from time to time?
Hello,
Would it be possible to add the newer versions for oc_uv_ab.patch and interactive governor or I just don't know how to use GIT to well?
I don't have too much experience with C++, PHP dev here , and I'd like to compile my own kernel from the official GIT + change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
dlsniper said:
change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
Click to expand...
Click to collapse
This would be great.If someone can guide us how to make our wifi mac address
dolby71 said:
how does it work?
Click to expand...
Click to collapse
Just sit down and relaxed lol,michelle (michyprima kernel) or the topic starter build them i guess in few days
Whoops,nevermind,old topic i see
As the topic states..
Can someone here give any explanation on the MSM_CPUFreq and Simple_Ondemand GPU governors?
Have searched on Google - but can't find anything about those two regarding benefits and non-benefits with one of em' enabled and choosen.
Msm_cpufreq i dont know about but Simple Ondemand is actually a Governor for the gpu to run efficiently e.g saving battery with minimal compromize for performance.
Hey!
First time using agni kernel on Nougat NOS rom, can someone please tell me best settings for balance performance? Like no lag, smooth but good battery backup?
Never used this kernel, only radon and still lag sometimes with balanced settings.
Thanks! Appreciate all info!
According to Agni dev, kernel will improve with time, I am also using Nitrogen with Agni, and I also experienced lags on first day. Wait for a full day of use, and don't turn your device off. It should improve.
icnn said:
Hey!
First time using agni kernel on Nougat NOS rom, can someone please tell me best settings for balance performance? Like no lag, smooth but good battery backup?
Never used this kernel, only radon and still lag sometimes with balanced settings.
Thanks! Appreciate all info!
Click to expand...
Click to collapse
Use this settings:
In Agni control all cpu Freq. To lowest ( MINIMUM and MAXIMUM both do it low Freq)
Big governer interactive glassfish, small governer interactive glassfish.
Hotplug - intelliplug
GPU Freq. To lowest in Agni control.
Lz4 zram off for 3gb ram and If 2gb ram variant then Lz4 zram 256 set.
Adreno idler on
In spectrum app, set profile to battery.
Last one can be ignored outdoor since it dims brightness.
Then save your current setting. and Reboot.
If it lags for you in beginning don't worry.
It will adapt your usage and it will be smooth the more you use.
Try this :-
Governor big cluster- Interactive glassfish
Governor small cluster- Interactive glassfish
CPU Max freq big cluster - 1612
CPU Max freq little cluster- 1382
CPU Min freq big cluster- default
CPU Min freq little cluster- default.
CPU hotplugging - Intelliplug
GPU Max freq- 550
GPU Min freq- 133
Adreno Idler - On
Z4 RAM - 500 mb
Rest all default.
Code:
/*
* Your warranty is now void.
*
* 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 ROM
* 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. Hard. A lot.
*/
ABOUT:
BlackScreen is my custom kernel made for custom aosp/caf roms
This started as just being the kernel in my aicp builds, but as more and more users of other roms started using it I realized I should make a separate thread
====================================================================================================
BlackScreen is meant to give you great battery life and performance (depending on how you tune it), essentially I tried to optimize it for everyday usage (gaming, media consumption. browsing the web, all that stuff), I'm not aiming to have the highest Antutu score (although it is very high, it's just not my focus), you see benchmarks don't really reflect actual everyday usage.
The main thing that I do is port good features and optimizations from the various OnePlus 3/3t kernels (they have many great kernel devs and a lot of their work can benefit us too), I also optimize the kernel settings and stuff like that
Currently BlackScreen is included in AICP, and GZR. It is based off of the android linux stable kernel by @nathanchance (He takes caf and upstreams it to the latest from linux stable), with the bringup from @codeworkx, I do my best to keep it up to date with lineage, and Android Linux stable
Downloads
https://www.androidfilehost.com/?w=files&flid=227246
Note:
The -oc zip is simply an overclocked version of the regular build
Install instructions:
In twrp go to the install page, flash the zip, and reboot
Here are some of the features
CPU:
Interactive governor
Ondemand governor
Conservative governor
Powersave governor
Performance governor
darkness governor
Lionfish governor
nebula governor
wheatley governor
lionheart governor
bioshock governor
impulse governor
Alucard governor
ConservativeX governor
Elementalx governor
Nightmare governor
Smartmax governor
Yankactive governor
Despair governor
blu_active governor
Optional overclock
Voltage control
Screen
kcal
Backlight dimmer
I/O:
Improved deadline
improved cfq
bfq
sio
fiops
tripndroid
sioplus
zen
maple
Virtual memory:
various optimizations
zram
zswap
entropy:
some optimizations
tcp-algorithms:
bic
westwood
htcp
hstcp
vegas
scalable
lp
veno
yeah
illinois
hybla
Misc:
fsync toggle
Many more optimizations
Several wakelocks have been blocked
Added the ability to tweak the thermal throttle settings for the CPU (be very careful with this)
USB fast charge
faster unlock
improved network performance
Option to enable/disable gentle fair sleepers
Option to enable/disable software crc control
vibrator intensity control
arch power savings
Thanks to:
darkobas
codeworkx
Sultanxda
Franco
Flar2
dabug123
GalaticStryder
nathanchance
KuranKaname
DD3Boh
There are many more
Source:
Telegram group:
https://t.me/BlackScreenKernel
Regular build:
https://github.com/AICP/kernel_leeco_msm8996/tree/o8.1
Overclocked build:
https://github.com/mosimchah/kernel_leeco_msm8996/tree/o8.1-oc
This is a work in progress guide to getting great battery life
Note: This guide is meant to be used on my kernel, there's several optimizations that I've left out of this guide because I enabled them by default in my kernel
1. Set the CPU governor to lionfish, or impulse (these will cause lags, interactive is really good enough though)
2. Underclock the big cores to 1900mhz
3. Set the GPU governor to simple_ondemand
4. Set the vibration strength to zero (or close to zero) in the misc section
5. Set the I/O scheduler to noop
6. Go to developer options and turn off the logger buffer sizes (you will have to turn this back on in order to get a logcat for bug reports, and to pass safety net)
7. Use greenify to enable aggressive doze and doze on the go, and use it to limit background apps
8. If you underclock the big cores even more in kernel adiutor you'll get much better battery life, you'll also get much better battery life if you underclock the little cores to 1440MHz (will cause lags under heavy usage)
9. Set all animation durations to .1, or .5 (depending on the options in your ROM) in developer options, never set it to zero on Oreo, it will cause weird issues and fc's in some apps #BlameGoogle
10. In kernel adiutor set the low memory killer values to the aggressive setting
11. Enable dynamic fsync
==================================================================================================================================================================================================================
This is a work in progress guide to getting great performance at the expense of battery life
Note: This guide is meant to be used on my kernel, there's several optimizations that I've left out of this guide because I enabled them by default in my kernel
1. Go to developer options and turn off the logger buffer sizes (you will have to turn this back on in order to get a logcat for bug reports)
2. Use greenify to enable aggressive doze and doze on the go, and use it to limit background apps
3. Set all animation durations to .1, or .5 (depending on the options in your ROM) in developer options, never set it to zero on Oreo, it will cause weird issues and fc's in some apps #BlameGoogle
4. Flash BlackScreen overclocked, and use a kernel manager app to set the freqs to the max for the CPU and GPU
5. Enable dynamic fsync
6. Enable ksm, for more free ram, good for gaming
7. Set the CPU governor to wheatley
Kernel Info
Here is some info on my Kernel builds
Info on kernel settings:
######################
CPU governors
source- http://androidmodguide.blogspot.com/p/blog-page.html?m=1
OnDemand:
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
Interactive:
Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
Alucard
A favorite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
Blu_active
A new cpu governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.
Bioshock
A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.
ConservativeX:
Also developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.
Conservative:
This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life
ConservativeX
Also developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.
Darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated version of the nightmare gov, so far it is quite stable in tests,
nightmare info:
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
Pegasusq info:
The Pegasusq / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand. 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 (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
Despair
It is a tweaked conservative governor with a couple extra values exposed, it tends to be a bit more conservative with battery than the conservative governor by default. Developed by DespairFactor.
ElementalX
ElementalX is basically a multiphase Ondemand governor that aims to achieve the best balance between battery life and performance. By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.
Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
Lionheart
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
Lionfish
The Lionfish governor combines traits of the conservative, ondemand, and interactive governors. It is designed to maximize battery life without noticeably impacting performance. It responds quickly to heavy loads (similar to ondemand and interactive) while staying within the region of optimal CPU performance per watt. With moderate loads, it periodically votes to raise, maintain, or decrease the frequency. When there are enough votes to change the frequency, it is ramped up and down gradually. The voting mechanism reduces frequency jitter compared to ondemand and conservative. squid2's testing had found that this governor uses moderate frequencies (where efficiency is optimal) more effectively than interactive, ondemand, and conservative. This improved frequency distribution results in a moderate reduction in CPU power consumption while maintaining responsiveness comparable to the interactive governor.
Nebula
A port of the Interactive governor based on msm-4.4 sources with some mods for the HTC 10, preserving the excellent balance between performance and battery life found in many other Interactive based govs. It originated from Eliminater74's Nebula kernel and was a popular choice prior to the introduction of EAS scheduling to the kernel.
Performance
The performance governor locks the phone's CPU at maximum frequency.
Powersave
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Smartmax
By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
Wheatley
This governor is build on “ondemand” but increases the C4 (the sleep state) state time of the CPU and doing so trying to save juice. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds. Obviously, this governor is only available on multi-core devices.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
Yankactive
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
I recommend using bioshock for everyday usage, wheatley or interactive for performance. and Impluse or lionfish for battery life
GPU governors (the recommended ones) source http://androidmodguide.blogspot.com/p/blog-page.html?m=1
simple_ondemand: As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
msm-adreno-tz: The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
I recommend using simple_ondemand for regular usage due to the battery savings
I/O schedulers: (the recommended ones)
source- http://androidmodguide.blogspot.com/p/io-schedulers.html?m=1
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, you should try deadline.
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), you can select this.
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.
Benefits:
- Has a well balanced I/O performance
- Excellent on multiprocessor systems
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
- Under constant load, the phone will experience increased I/O latency due to the way how the scheduler tries to create 'fairness'
The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.
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.
Benefits:
- Has a very good USB data transfer rate.
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
- Good for multitasking, more responsive than CFQ
Disadvantages:
- Not the best scheduler for benchmarks
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.
SIO (Simple):
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
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
- Not the best scheduler for benchmarks
The bottom line:It is a good all-round scheduler. People who want better performance should avoid using this.
FIOPS (Fair IOPS):
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Achieves high read and write speeds in benchmarks
- Faster app launching time and overall UI experience
Disadvantages:
- Not the most responsive IO scheduler (Can make phone lag)
- Not good at heavy multitasking
The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.
ZEN
ZEN is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.
VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, more polished
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.
SIOplus
Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).
Benefits:
- Better read and write speeds than previous SIO scheduler
Disadvantages:
- Fluctuations in performance may be observed
The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where
Tripndroid
A new I/O scheduler based on Noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Great at IO performance and everyday multitasking
- Well rounded and efficient IO scheduler
- Very responsive I/O scheduler (Compared to FIOPS)
Disadvantages:
- Performance varies between different devices (Some devices perform really well, I haven't tested it much on zl1)
The bottom line: Tripndroid isn't really common, there are other schedulers you can choose which may perform similar or better
Maple
Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
Disadvantages:
- Performance varies between different devices (Some devices perform really well)
The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.
Summary:
Use noop or sioplus for battery life, bfq or Maple for multitasking, fiops for gaming, sioplus or cfq for stability, and deadline for all around performance
CONTINUED ON THE NEXT POST
More info on kernel settings:
Low Memory Killer
source- http://androidcentral.com/fine-tuning-minfree-settings-improving-androids-multi-tasking
FOREGROUND_APP: This is the application currently on the screen, and running
VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something
SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something
HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running
For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:
CONTENT_PROVIDER: This is apps that provide data (content) to the system. Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Google play store. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.
EMPTY_APP:They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes
Virtual Memory this is the really fun stuff
source- the Linux kernel documentation https://github.com/AICP/kernel_leeco_msm8996/blob/o8.0/Documentation/sysctl/vm.txt
dirty_background_ratio:
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data.
The total available memory is not equal to total system memory.
dirty_ratio:
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
The total available memory is not equal to total system memory.
dirty_expire_centisecs:
This tunable is used to define when dirty data is old enough to be eligible for write out by the kernel flusher threads. It is expressed in 100'ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a flusher thread wakes up.
dirty_writeback_centisecs:
The kernel flusher threads will periodically wake up and write `old' data out to disk. This tunable expresses the interval between those wakeups, in 100'ths of a second.
Setting this to zero disables periodic write back altogether.
extra_free_kbytes:
This parameter tells the VM to keep extra free memory between the threshold where background reclaim (kswapd) kicks in, and the threshold where direct reclaim (by allocating processes) kicks in.
This is useful for workloads that require low latency memory allocations and have a bounded burstiness in memory allocations, for example, a realtime application that receives and transmits network traffic (causing in-kernel memory allocations) with a maximum total message burst size of 200MB may need 200MB of extra free memory to avoid direct reclaim related latencies.
min_free_kbytes:
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system.
Each lowmem zone gets a number of reserved free pages based proportionally on its size.
Some minimal amount of memory is needed to satisfy PF_MEMALLOC allocations; if you set this to lower than 1024KB, your system will become subtly broken, and prone to deadlock under high loads.
Setting this too high will OOM your machine instantly.
oom_kill_allocating_task:
This enables or disables killing the OOM-triggering task in out-of-memory situations.
If this is set to zero, the OOM killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.
If this is set to non-zero, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive tasklist scan.
If panic_on_oom is selected, it takes precedence over whatever value is used in oom_kill_allocating_task.
The default value is 0.
swappiness:
This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
zRam
source- https://source.android.com/devices/tech/debug/jank_jitter#page-cache
zRam creates a compressed swap file in your RAM. The compression factor is the gain: with that, you "increase" your RAM. This improves performance, even on a device with 4/6GB of RAM
Misc
Vibration strength:
Obviously this controls the strength of the vibrations, setting this to a lower value will increase battery life, setting it to zero will disable all vibrations (Kind of, you'll still get a very subtle vibration, but chances are you won't even notice it)
TCP CONGESTION ALGORITHMS:
source- http://androidmodguide.blogspot.com/p/tcp-algorithms.html?m=1
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Vegas:
One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Veno:
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
Low Priority (LP):
A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
Binary Increase Congestion control (BIC):
BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.
Scalable:
Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
Hamilton TCP (HTCP):
HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.
Illinois:
Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
High speed (HSTCP):
High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.
Yeah-TCP:
A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
I recommend using Westwood for everything, and only use cubic if all you care about is maximum stability and don't mind losses in performance, and latency, and stuff like that
mosimchah said:
reserved.
Click to expand...
Click to collapse
Excelent newsssss!!!!
Enviado desde mi iPad utilizando Tapatalk
yeesssss!!!!
################################################################
BlackScreen 4.1################################################################
Changes:
1. Updated to Linux 3.18.80 (from 3.18.78)
2. Changed the default cpu governor to bioshock, this will improve battery life (compared to interactive)
3. re-enabled the ipa wakelock, disabling this creates another wakelock which is even worse (you can still disable it if you want)
Download: https://www.androidfilehost.com/?fid=817906626617945015
don't forget to flash supersu or magisk afterwords if you don't want to lose root
Sent from my LEX727 using XDA Labs
My favourite Nougat kernel now for the Oreo!! Thank you
Finally had some time to add my battery life/performance guide, and extra kernel info to my reserved posts
Battery life/performance guide:
https://forum.xda-developers.com/showpost.php?p=74363632&postcount=2
Kernel info:
https://forum.xda-developers.com/showpost.php?p=74363637&postcount=3
https://forum.xda-developers.com/showpost.php?p=74363641&postcount=4
Sent from my LEX727 using XDA Labs
################################################################
BlackScreen 4.2################################################################
Changes:
1. Updated the kernel to Linux 3.18.84 (from 3.18.80)
2. Merged the latest caf tag (tons and tons of changes in it)
3. Updated to the latest qcacld-2.0
As always there's more info on the kernel features (cpu, and gpu governors, hotplug driver, IO schedulers, tcp algorithms, and way more) in the third post, and fourth post, and I have a great battery life and performance guide in the second post
Download: https://www.androidfilehost.com/?fid=962021903579495149
don't forget to flash supersu or magisk afterwords if you don't want to lose root
Sent from my LEX727 using XDA Labs
@mosimchah Will u please make one caynogen based highly overclocked kernel for le x722 elite pro 3. so that x722's sd 820 can also match the speed of snapdragon821 . Thankuhh in advance!!!
Yugps said:
@mosimchah Will u please make one caynogen based highly overclocked kernel for le x722 elite pro 3. so that x722's sd 820 can also match the speed of snapdragon821 . Thankuhh in advance!!!
Click to expand...
Click to collapse
First get my Kernel, or the Lineage kernel working on your device, then I'll add the overclock
Sent from my LEX727 using XDA Labs
mosimchah said:
First get my Kernel, or the Lineage kernel working on your device, then I'll add the overclock
Sent from my LEX727 using XDA Labs
Click to expand...
Click to collapse
https://drive.google.com/file/d/1JgfAbcz4Gm32RTUTwOjiPhU-Fi6y10_2/view?usp=drivesdk
This is the link for the working caynogen based kernel on my device le x722 elite. So please add overclock frequencies of big cluster upto 2.35 or 2.4 ghz , litle clusters upto 1.9 or 2 ghz , gpu frequency upto 700 mhz. and thankuh so much for responding @mosimchah .
Yugps said:
https://drive.google.com/file/d/1JgfAbcz4Gm32RTUTwOjiPhU-Fi6y10_2/view?usp=drivesdk
This is the link for the working caynogen based kernel on my device le x722 elite. So please add overclock frequencies of big cluster upto 2.35 or 2.4 ghz , litle clusters upto 1.9 or 2 ghz , gpu frequency upto 700 mhz. and thankuh so much for responding @mosimchah .
Click to expand...
Click to collapse
I would need the Kernel source for one, and it needs to be this kernel or the official lineage Kernel, I'm not going to add the overclocks if the kernel won't even work with your device
Sent from my LEX727 using XDA Labs
mosimchah said:
I would need the Kernel source for one, and it needs to be this kernel or the official lineage Kernel, I'm not going to add the overclocks if the kernel won't even work with your device
Sent from my LEX727 using XDA Labs
Click to expand...
Click to collapse
So from where i will get the kernel source of this lineage one.
https://drive.google.com/file/d/100PA3BCfRZqgHv1TCRr8AopZm1v9PF6g/view?usp=drivesdk. (Screenshot)
And the rom which i am using is the ported ressurection remix x727 zl1 to Zl0 x722 even bugs are the same and the kernel which i have provided above is extracted from this rom. Edited
Yugps said:
So from where i will get the kernel source of this lineage one.
Click to expand...
Click to collapse
Ask the Kernel dev, and again it has to be this Kernel or the official Lineage one, so it doesn't matter if that other kernel works, I'm not going to maintain two completely different kernels
Sent from my LEX727 using XDA Labs
mosimchah said:
Ask the Kernel dev, and again it has to be this Kernel or the official Lineage one, so it doesn't matter if that other kernel works, I'm not going to maintain two completely different kernels
Sent from my LEX727 using XDA Labs
Click to expand...
Click to collapse
I edited my above post please read again thank you and i will ask @frantisheq for the source code of kernel
@mosimchah
I love your kernel builds, is there any reason I can put this on a 7.1 build? I'm still waiting on a Android 8...
BlocforLife said:
@mosimchah
I love your kernel builds, is there any reason I can put this on a 7.1 build? I'm still waiting on a Android 8...
Click to expand...
Click to collapse
You can't use this on nougat because it's an Oreo kernel, also, I have a separate thread for nougat, so use those builds
Sent from my LEX727 using XDA Labs
Yugps said:
I edited my above post please read again thank you and i will ask @frantisheq for the source code of kernel
Click to expand...
Click to collapse
That's not the kennel source, and again it doesn't matter if that kernel works, you need to get this Kernel working, or the official lineage Kernel
Sent from my LEX727 using XDA Labs
Code:
/*
* Your warranty is now void.
*
* 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 ROM
* 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. Hard. A lot.
*/
ABOUT:
BlackScreen is my custom kernel made for custom aosp/caf roms
This started as just being the kernel in my aicp builds, but as more and more users of other roms started using it I realized I should make a separate thread
================================================== ==================================================
BlackScreen is meant to give you great battery life and performance (depending on how you tune it), essentially I tried to optimize it for everyday usage (gaming, media consumption. browsing the web, all that stuff), I'm not aiming to have the highest Antutu score (although it is very high, it's just not my focus), you see benchmarks don't really reflect actual everyday usage.
The main thing that I do is port good features and optimizations from the various OnePlus 3/3t kernels (they have many great kernel devs and a lot of their work can benefit us too), I also optimize the kernel settings and stuff like that
Currently BlackScreen is included in AICP, and GZR. It is based off of the android linux stable kernel by @nathanchance (He takes caf and upstreams it to the latest from linux stable), with the bringup from @codeworkx, I do my best to keep it up to date with lineage, and Android Linux stable
Downloads
Normal build
OC build
Note:
The -oc zip is simply an overclocked version of the regular build
Install instructions:
In twrp go to the install page, flash the zip, and reboot
Here are some of the features
CPU:
Interactive governor
Ondemand governor
Conservative governor
Powersave governor
Performance governor
darkness governor
Lionfish governor
nebula governor
wheatley governor
lionheart governor
bioshock governor
impulse governor
Alucard governor
ConservativeX governor
Elementalx governor
Nightmare governor
Smartmax governor
Yankactive governor
Despair governor
blu_active governor
Optional overclock
Voltage control
GPU:
Adreno boost
Adreno idler
Screen
kcal
Backlight dimmer
I/O:
Improved deadline
improved cfq
bfq
sio
fiops
tripndroid
sioplus
zen
maple
Virtual memory:
various optimizations
zram
zswap
ksm
entropy:
some optimizations
tcp-algorithms:
bic
westwood
htcp
hstcp
vegas
scalable
lp
veno
yeah
illinois
hybla
Misc:
dynamic fsync toggle
Many more optimizations
Several wakelocks have been blocked
Added the ability to tweak the thermal throttle settings for the CPU (be very careful with this)
USB fast charge
faster unlock
improved network performance
Option to enable the disabled gentle fair sleepers
Option to enable software crc control
vibrator intensity control
arch power savings
Thanks to:
darkobas
codeworkx
Sultanxda
Franco
Flar2
dabug123
GalaticStryder
nathanchance
mosimchah
DD3Boh
There are many more
Source:
Telegram group:
https://t.me/BlackScreenKernel
Regular build:
https://github.com/AICP/kernel_leeco_msm8996/tree/o8.1
Overclocked build:
https://github.com/mosimchah/kernel_leeco_msm8996/tree/o8.1-oc
XDA:DevDB Information
[KERNEL] [8.x] BlackScreen (for the Max2 aka x2, X820,X822,x829), Kernel for the LeEco Le Max 2
Contributors
KuranKaname
Kernel Special Features:
Version Information
Status: Stable
Created 2018-07-14
Last Updated 2018-08-08
This is a work in progress guide to getting great battery life
Note: This guide is meant to be used on my kernel, there's several optimizations that I've left out of this guide because I enabled them by default in my kernel
1. Set the CPU governor to lionfish, or impulse (these will cause lags, interactive is really good enough though)
2. Underclock the big cores to 1900mhz
3. Set the GPU governor to simple_ondemand
4. Set the vibration strength to zero (or close to zero) in the misc section
5. Set the I/O scheduler to noop
6. Go to developer options and turn off the logger buffer sizes (you will have to turn this back on in order to get a logcat for bug reports, and to pass safety net)
7. Use greenify to enable aggressive doze and doze on the go, and use it to limit background apps
8. If you underclock the big cores even more in kernel adiutor you'll get much better battery life, you'll also get much better battery life if you underclock the little cores to 1440MHz (will cause lags under heavy usage)
9. Set all animation durations to .1, or .5 (depending on the options in your ROM) in developer options, never set it to zero on Oreo, it will cause weird issues and fc's in some apps #BlameGoogle
10. In kernel adiutor set the low memory killer values to the aggressive setting
11. Enable dynamic fsync
================================================== ================================================== ================================================== ================================================== ==========
This is a work in progress guide to getting great performance at the expense of battery life
Note: This guide is meant to be used on my kernel, there's several optimizations that I've left out of this guide because I enabled them by default in my kernel
1. Go to developer options and turn off the logger buffer sizes (you will have to turn this back on in order to get a logcat for bug reports)
2. Use greenify to enable aggressive doze and doze on the go, and use it to limit background apps
3. Set all animation durations to .1, or .5 (depending on the options in your ROM) in developer options, never set it to zero on Oreo, it will cause weird issues and fc's in some apps #BlameGoogle
4. Flash BlackScreen overclocked, and use a kernel manager app to set the freqs to the max for the CPU and GPU
5. Enable dynamic fsync
6. Enable ksm, for more free ram, good for gaming
7. Set the CPU governor to wheatley
Kernel Info
Here is some info on my Kernel builds
Info on kernel settings:
######################
CPU governors
source- http://androidmodguide.blogspot.com/...-page.html?m=1
OnDemand:
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
Interactive:
Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
Alucard
A favorite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
Blu_active
A new cpu governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.
Bioshock
A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.
ConservativeX:
Also developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.
Conservative:
This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life
ConservativeX
Also developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.
Darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated version of the nightmare gov, so far it is quite stable in tests,
nightmare info:
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
Pegasusq info:
The Pegasusq / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand. 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 (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
Despair
It is a tweaked conservative governor with a couple extra values exposed, it tends to be a bit more conservative with battery than the conservative governor by default. Developed by DespairFactor.
ElementalX
ElementalX is basically a multiphase Ondemand governor that aims to achieve the best balance between battery life and performance. By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.
Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
Lionheart
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
Lionfish
The Lionfish governor combines traits of the conservative, ondemand, and interactive governors. It is designed to maximize battery life without noticeably impacting performance. It responds quickly to heavy loads (similar to ondemand and interactive) while staying within the region of optimal CPU performance per watt. With moderate loads, it periodically votes to raise, maintain, or decrease the frequency. When there are enough votes to change the frequency, it is ramped up and down gradually. The voting mechanism reduces frequency jitter compared to ondemand and conservative. squid2's testing had found that this governor uses moderate frequencies (where efficiency is optimal) more effectively than interactive, ondemand, and conservative. This improved frequency distribution results in a moderate reduction in CPU power consumption while maintaining responsiveness comparable to the interactive governor.
Nebula
A port of the Interactive governor based on msm-4.4 sources with some mods for the HTC 10, preserving the excellent balance between performance and battery life found in many other Interactive based govs. It originated from Eliminater74's Nebula kernel and was a popular choice prior to the introduction of EAS scheduling to the kernel.
Performance
The performance governor locks the phone's CPU at maximum frequency.
Powersave
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Smartmax
By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
Wheatley
This governor is build on “ondemand” but increases the C4 (the sleep state) state time of the CPU and doing so trying to save juice. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds. Obviously, this governor is only available on multi-core devices.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
Yankactive
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
I recommend using bioshock for everyday usage, wheatley or interactive for performance. and Impluse or lionfish for battery life
GPU governors (the recommended ones) source http://androidmodguide.blogspot.com/...-page.html?m=1
simple_ondemand: As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
msm-adreno-tz: The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
I recommend using simple_ondemand for regular usage due to the battery savings
I/O schedulers: (the recommended ones)
source- http://androidmodguide.blogspot.com/...ulers.html?m=1
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, you should try deadline.
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), you can select this.
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.
Benefits:
- Has a well balanced I/O performance
- Excellent on multiprocessor systems
- Regarded as a stable I/O scheduler
- Good for multitasking
Disadvantages:
- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
- Under constant load, the phone will experience increased I/O latency due to the way how the scheduler tries to create 'fairness'
The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.
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.
Benefits:
- Has a very good USB data transfer rate.
- The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
- Good for multitasking, more responsive than CFQ
Disadvantages:
- Not the best scheduler for benchmarks
- Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.
SIO (Simple):
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
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
- Not the best scheduler for benchmarks
The bottom line:It is a good all-round scheduler. People who want better performance should avoid using this.
FIOPS (Fair IOPS):
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Achieves high read and write speeds in benchmarks
- Faster app launching time and overall UI experience
Disadvantages:
- Not the most responsive IO scheduler (Can make phone lag)
- Not good at heavy multitasking
The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.
ZEN
ZEN is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.
VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
- More stable than VR, more polished
Disadvantages:
- Performance variability can lead to different results (Only performs well sometimes)
The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.
SIOplus
Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).
Benefits:
- Better read and write speeds than previous SIO scheduler
Disadvantages:
- Fluctuations in performance may be observed
The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where
Tripndroid
A new I/O scheduler based on Noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Great at IO performance and everyday multitasking
- Well rounded and efficient IO scheduler
- Very responsive I/O scheduler (Compared to FIOPS)
Disadvantages:
- Performance varies between different devices (Some devices perform really well, I haven't tested it much on zl1)
The bottom line: Tripndroid isn't really common, there are other schedulers you can choose which may perform similar or better
Maple
Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
Benefits:
- Well rounded IO Scheduler
- Very efficient IO Scheduler
Disadvantages:
- Performance varies between different devices (Some devices perform really well)
The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.
Summary:
Use noop or sioplus for battery life, bfq or Maple for multitasking, fiops for gaming, sioplus or cfq for stability, and deadline for all around performance
CONTINUED ON THE NEXT POST
More info on kernel settings:
Low Memory Killer
source- http://androidcentral.com/fine-tunin...-multi-tasking
FOREGROUND_APP: This is the application currently on the screen, and running
VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something
SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something
HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running
For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:
CONTENT_PROVIDER: This is apps that provide data (content) to the system. Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Google play store. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.
EMPTY_APP:They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes
Virtual Memory this is the really fun stuff
source- the Linux kernel documentation https://github.com/AICP/kernel_leeco.../sysctl/vm.txt
dirty_background_ratio:
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which the background kernel flusher threads will start writing out dirty data.
The total available memory is not equal to total system memory.
dirty_ratio:
Contains, as a percentage of total available memory that contains free pages and reclaimable pages, the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
The total available memory is not equal to total system memory.
dirty_expire_centisecs:
This tunable is used to define when dirty data is old enough to be eligible for write out by the kernel flusher threads. It is expressed in 100'ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a flusher thread wakes up.
dirty_writeback_centisecs:
The kernel flusher threads will periodically wake up and write `old' data out to disk. This tunable expresses the interval between those wakeups, in 100'ths of a second.
Setting this to zero disables periodic write back altogether.
extra_free_kbytes:
This parameter tells the VM to keep extra free memory between the threshold where background reclaim (kswapd) kicks in, and the threshold where direct reclaim (by allocating processes) kicks in.
This is useful for workloads that require low latency memory allocations and have a bounded burstiness in memory allocations, for example, a realtime application that receives and transmits network traffic (causing in-kernel memory allocations) with a maximum total message burst size of 200MB may need 200MB of extra free memory to avoid direct reclaim related latencies.
min_free_kbytes:
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a watermark[WMARK_MIN] value for each lowmem zone in the system.
Each lowmem zone gets a number of reserved free pages based proportionally on its size.
Some minimal amount of memory is needed to satisfy PF_MEMALLOC allocations; if you set this to lower than 1024KB, your system will become subtly broken, and prone to deadlock under high loads.
Setting this too high will OOM your machine instantly.
oom_kill_allocating_task:
This enables or disables killing the OOM-triggering task in out-of-memory situations.
If this is set to zero, the OOM killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.
If this is set to non-zero, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive tasklist scan.
If panic_on_oom is selected, it takes precedence over whatever value is used in oom_kill_allocating_task.
The default value is 0.
swappiness:
This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
zRam
source- https://source.android.com/devices/t...ter#page-cache
zRam creates a compressed swap file in your RAM. The compression factor is the gain: with that, you "increase" your RAM. This improves performance, even on a device with 4/6GB of RAM
Misc
Vibration strength:
Obviously this controls the strength of the vibrations, setting this to a lower value will increase battery life, setting it to zero will disable all vibrations (Kind of, you'll still get a very subtle vibration, but chances are you won't even notice it)
TCP CONGESTION ALGORITHMS:
source- http://androidmodguide.blogspot.com/...ithms.html?m=1
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Vegas:
One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Veno:
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
Low Priority (LP):
A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
Binary Increase Congestion control (BIC):
BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.
Scalable:
Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
Hamilton TCP (HTCP):
HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.
Illinois:
Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
High speed (HSTCP):
High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.
Yeah-TCP:
A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
I recommend using Westwood for everything, and only use cubic if all you care about is maximum stability and don't mind losses in performance, and latency, and stuff like that
I Can say it is very good, and performance is really noticeable.
I tried so many ROMS, AICP was easily the best and now i know why.
keep it up.
I like new software thingies for our devices. Thank you... ?
I have installed it on MSM which is already having blackscreen . I didnt notice any improvement in performance .....battery drain i am testing it now.. will update soon
venky83 said:
I have installed it on MSM which is already having blackscreen . I didnt notice any improvement in performance .....battery drain i am testing it now.. will update soon
Click to expand...
Click to collapse
This release was a kernel clean up from all the crappy stuff and some things done a bit different
When will you upload a zip with oc kernel?
This might be a stupid question, but where do you find the options to follow your battery saving guide? Is it in the settings somewhere or via an app you have to install?
I'm on MSM.
Installed on Aosip the battery drops very quickly even without using the phone
The best described thread I have seen! Using with ACIP .Sot 3.30h but my battery is dead :/
immortal68 said:
this might be a stupid question, but where do you find the options to follow your battery saving guide? Is it in the settings somewhere or via an app you have to install?
I'm on msm.
Click to expand...
Click to collapse
ka, fku, ekm
https://drive.google.com/file/d/1n3MXmTCf9YX7VB5JaqOUvVA7xqe4DQUH/view?usp=sharing
OC build
KuranKaname said:
ka, fku, ekm
Click to expand...
Click to collapse
Sorry, what? I don't know what this is supposed to mean.
Immortal68 said:
Sorry, what? I don't know what this is supposed to mean.
Click to expand...
Click to collapse
Did you check page 1 completely?
rohit3192 said:
Did you check page 1 completely?
Click to expand...
Click to collapse
I skimmed over everything a few times already. There are a few dead links for me, but nothing I saw answered my question.
Maybe my wording was unclear? To reiterate: How do you change governors and the rest pointed out in #2? Do you need an app for that? Or is it embedded in android settings?
Immortal68 said:
Sorry, what? I don't know what this is supposed to mean.
Click to expand...
Click to collapse
Kernel Adiutor, franco kernel manager, EX Kernel Manager. All those are apps on the play store. Kernel adiutor is free. You also need root
Immortal68 said:
I skimmed over everything a few times already. There are a few dead links for me, but nothing I saw answered my question.
Maybe my wording was unclear? To reiterate: How do you change governors and the rest pointed out in #2? Do you need an app for that? Or is it embedded in android settings?
Click to expand...
Click to collapse
Yeah I know the links are dead. Didn't have time to fix those little ****ers
@KuranKaname
nAice MAN!!!
Long time...
Good to see you been following op3/t kernels
Could not see if OP mentions compatible ROMs...
few keywords EAS, kernel hardening from CopperheadOS, DTS eagle, any good features from Lambda kernel
Please comment if you are considering any of it/already included
If you include it(i know it's DAMN hard) will switch to lemax 2 from my 3T
@KuranKaname Is it possible to add dt2s?