Related
I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
The 6th patch 0006-mach-s5pv310-cpufreq-smooth-scaling.patch is specific for the GT-I9100 hardware. It is needed to fix a wrong behavior with governors that run at a fixed frequency (like 'performance', 'powersave' or 'userspace'). Basically, the low-level driver doesn't allow to switch from a very low frequency to a very high frequency, so in some cases the actual cpu frequency can be different than the frequency requested by the higher layers. This fix introduces a smooth scaling mechanism in the low-level driver that allows to switch to the target frequency incrementally in multiple steps.
Everything is transparent to the higher layers, so in this way we are sure that the actual cpu frequency is always the same value requested by the cpufreq governor. See also the commit in my kernel on github.
NOTE: the last patch (0006-mach-s5pv310-cpufreq-smooth-scaling.patch) is a fix for the low-level cpufreq driver of the GT-I9100 that should be _always_ applied IMHO, even without the dynamic cpufreq range regulation patch.
ChangeLog
v2 -> v3
fix a wrong behavior (cpu stuck at 800MHz) with fixed-frequency governors (i.e, performance, powersave, or userspace).
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Looks promising, hope it works well, will sure try it out, but some kernels has almost the same built in...
Great work!
Uploaded a new version of the dynamic frequency range regulation patch.
There're two additional patches in the patch set:
The first patch (0004) is a fix that allows to properly offline the secondary cpu when screen is on.
The other patch (0005) applies the same concept of the dynamic frequency range regulation to the secondary cpu hotplugging: when the screen is off also the secondary cpu (cpu1) is kept offline, when the screen is on the secondary cpu is turned on/off depending on the load on the primary cpu (cpu0).
thanks a lot for your hard work.apply patch without problem, good for battery life.
a developper like me is very happy to have a master developper like you.
thank you very much it looks cool.
a noob question, how will I apply this zip just CWM or what?
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
pixiebob said:
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
Click to expand...
Click to collapse
hmm i see i wish you had a cwm flashable file for this to apply
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
flash with odin or heimdall:
http://www.megaupload.com/?d=TCQFKISK
commit:
https://github.com/pixiebob/pixie-kernel/commits/master
pixiebob said:
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
Click to expand...
Click to collapse
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
what kernels have this built in (if any)
cheers
@arighi great job on the patches... looking forward to more cool stuff from you.
Great patch, thank you.
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey pongster, you are always hanging around here!! When can we see your rom running all tweaks and fixes... looking forward to it...
Sent from my GT-I9100
arighi said:
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
Click to expand...
Click to collapse
thanks i will be careful but until by now i didn't have crash
great patch! I was also working on something similar but your patch is so complete that I gave up working and used yours
just a perfect patch!
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
v-b-n said:
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
Click to expand...
Click to collapse
cooking something up... not a MIUI based one though...
PM me
arighi said:
I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
ChangeLog
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Click to expand...
Click to collapse
Hi,
Can you make it also for ninphetamine source code?
netchip said:
Hi,
Can you make it also for ninphetamine source code?
Click to expand...
Click to collapse
All the patches apply fine, except patch 0003, because the ninphetamine kernel already has a 800MHz sleep death fix.
The following patch set should apply cleanly (UNTESTED!!!).
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?
This thread is all about kernel things. I will be trying to provide a brief explanation regarding most of the features & options available in custom kernels. There are two custom kernel which are maintained for our device.
Disclaimer: I in no way claiming that information available in this thread is 100% correct.
Brief History about these custom kernels.
1. Chimera Kernel by rupanshji
This is a custom kernel based on Nichcream & Team Reloaded’s kernel source code with features added by the developer. This kernel has spectrum support. Talking about updates, Chimera is not updated frequently.
Source Code | Thread
Download link: Google Drive | Older Builds
2. Jasper Kernel by Pawan.S 5277!
This is a custom kernel based on msm-3.18 kernel source code with features and patches added by the developer. Jasper is updated whenever a new CAF tag is available (as mentioned in OP & what I have noticed).
Source Code | Thread
Download link: AndroidFileHost | MediaFire
3. Spicy Kernel by DyWN
Temporarily discontinued.
Kernel Managers
EX Kernel Manager
Kernel Auditor
Features and Options available in at-least one of the custom kernels mentioned above are mentioned below along with a brief description about them.
GOVERNORS
1. Alucard: This govenor 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.
2. Blu_active: A 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.
3. Clarity: Basically this from interactive CAF with additional tunables and tweaks. such as: Remove boost functional - Limit max frequency when screen off. Using relation CPU frequency Current (C) (Low power as possible). - additional down load tunable.
4. Conservative: This governor biases the phone to prefer the lowest possible clock-speed 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.
The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
5. Darkness: It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests.
6. Electron: This is a governor based on interactive from the latest MSM8994 CAF branch with more upstream improvements, powersave bias, screen off max frequency, and some other tweaks to improve battery life without hindering performance.
7. Interactive: This governor 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.
8. Lisi: This governor is less aggressive and works similar to Alessa. This driver adds a dynamic cpufreq policy governor & designed for latency-sensitive workloads. The governor does a periodic polling and changes frequency based on the CPU utilization.
9. Nightmare: 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.
10. Ondemand: This 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.
11. Performance: The performance governor locks the phone's CPU at maximum frequency.
12. Powersave: The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
13. Schedutil: This is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.
14. 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.
CPU Scheduler options... Search yourself.
THERMAL
1. Msm thermal is a kernel platform driver which regulates thermal conditions on the device during kernel boot. The goal of MSM_THERMAL is to prevent the temperature of the system from exceeding a thermal limit at which it cannot operate. Examples are CPU junction thermal limit, or POP memory thermal limit. The MSM_THERMAL driver polls the TSENS sensor hardware during boot, and reduces the maximum CPU frequency allowed in steps, to limit power/thermal output when a threshold temperature is crossed. It restores the maximum CPU frequency allowed in the same stepwise fashion when the threshold temperature (with hysteresis gap) is cleared.
2. Core Control Enable / disable throttling, this enables the thermal engine and enable VDD restriction and core throttle.
3. VDD Restriction Limits CPU voltage, limiting it will decrease temperature.
HOTPLUG OPTIONS
1. AiO_hotplug: An all in one HotPlug for Traditional Quad-Core and Hexa/Octa-Core big.LITTLE SoCs.
2. Autosmp: A highly-efficient hotplug driver, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
GPU OPTIONS
Min GPU Freq: 216Mhz Max GPU Freq: 500 Mhz
GPU Governor:
1. 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.
2. 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.
3. Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
4. 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.
Note: There are many other broken GPU Governors. Do not select them. If you are using Chimera, then your device will reboot if you try to select them.
GPU Boost: If you are using msm-adreno-tz governor, then you can configure GPU boost option also. Use ExKM to configure this additional option.
Adreno Idler: It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
COLOR CONTROL
Self-explanatory
SCREEN OPTIONS
Backlight Dimmer: Enable only at night times.
GESTURE OPTIONS
1. DoubleTap2Wake
2. Sweep2Wake
3. Sweep2Sleep
All of them are self-explanatory
Pro tip: Use KA if using chimera or ExKM if using Jasper to configure gesture options.
GESTURE VIBRATION
You can the intensity of vibration for the gestures.
VOLTAGE
You can decrease or increase the voltage globally or per core by adjusting the values.
Pro tip: Just don’t play with this unless you’re pro. AFAIK, both custom kernels have under-voltage values according to CPU cluster so doing further can for sure cause in-stability issues.
SOUND
You can decrease or increase the headphone digital gain, mic gain or speaker gain by configuring settings under sound tab.
MEMORY
Low Memory Killer: is a process killer, which is designed to work in cooperation with the Android Framework. Each process is assigned a special value by the Framework when started, the oom_adj value(oom_score_adj on newer kernels). This value defines how important the process is for the system(its priority), and thus how easily it can be killed. Values vary between -17 and +15(0 to 1000 for oom_score_adj). Higher values are given to less important processes which are killed first. Moreover, LMK defines 5 different categories for processes, each one containing processes with oom_adj/oom_score_adj in a specific range of values:
1. Foreground Applications: The application currently shown on the screen and running.
2. Visible Applications Applications that might not be shown on the screen currently, but are still running. They might be hidden behind an overlay or have a transparent window.
3. Secondary Server Services running in the background and needed for Apps to function properly. This category includes Google Play Services for example.
4. Hidden Applications Applications that are hidden from the user, but are running in the background.
5. Content Providers These are the services providing content to the system like contacts provider, location provider etc.
6. Empty Applications This category contains Applications that the user exited, but Android still keeps in RAM. They do not steal any CPU time or cause any power drain.
ZRAM OPTIONS
zRAM is just compressed RAM space. So you can store more in RAM by compressing the data you can fit more data inside your RAM.
Now obviously it is slower than actual normal RAM (since you have to encrypt and decrypt the data), but apparently it still is faster than using swap (which is in your internal memory rather than RAM). The principle works based on that Android prefers to keep data stored as much as possible in RAM to keep recently used apps running quickly. The more you use an app the more priority it has, therefore will stay in normal RAM, things you use sometimes but not very often are kept in zRAM (regardless of how full your actual RAM is), but since you don't use this very often you don't notice the performance hiccup of decrypting that data.
Then last case scenario things you barely use are kept in swap.
For you IT enthusiasts you should have realised already that "z" is the technology prefix for Compression. So it shouldn't come as a surprise that zRAM is compressed RAM.
zRAM Size: 1 GiB is a fairly balanced amount. According to Google, it is useful even on devices with 4 GB of ram because it helps reduce page cache
thrashing, or constant unloading and reloading of cached pages from disk.
zRAM Compression: lzo or lz4
VIRTUAL MEMORY OPTIONS
Dirty Ratio & Dirty Background Ratio: Most people say that these need to be high, so that more stuff is stored in Cache. This will make your phone quick. Because cache is quick. But in reality this is only good advice if all you need to load on your phone is the system UI. Because as soon as you start loading different apps this cache fills quickly, and whenever you want to open an app/file/webpage that is not in cache, your CPU is tasked with both emptying whatever is filling up cache memory and load your new app into cache. Thus making multitasking a nightmare within the first day. A simple reboot of the phone is not enough, nor is clearing RAM (Note: Cache is not RAM).
Overcommit Ratio: While increasing allows more multitasking, I recommend leaving this at 0. It keeps RAM from completely filling up, thus avoiding "app xxx not responding" issues.
I/O OPTIONS
I/O Scheduler:
1. 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.
2. CFQ: This 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.
3. 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.
4. Fiops: 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) I/O scheduler 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.
5. 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.
6. 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.
7. Sio: 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.
8. Zen: It 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.
More info can be found here.
MISCELLANEOUS
TCP Congestion algorithm: Available choices are bic, cubic, lp, reno & westwood.
More info can be found here.
My recommendation: Try both custom kernel for atleast two days and then decide which suits your need. And use ExKM to configure Jasper as some of the options available in that kernel are not available in KA.
References: Source 1 | Source 2 | Source 3
Reserved
Thnx its very usefull to know about the governers
Nois tutorial!
Just a correction. You can use exKernel manager with chimera. I recommend KA to prevent piracy. Most of the peeps pirate exkernel manager usually.
rupanshji said:
Nois tutorial!
Just a correction. You can use exKernel manager with chimera. I recommend KA to prevent piracy. Most of the peeps pirate exkernel manager usually.
Click to expand...
Click to collapse
I mentioned KA for Chimera because when i tried this kernel, Wake gestures were working better with KA and not EX Kernel Manager.
If you want, I can amend OP according to your preference.
Nice good topic, thanks
There are so many questions asked over and over again about how to configure the kernel for a desired outcome..... max performance, best battery holdup, fix freezing etc.
I will post this for those who did not attend school just for the bus ride or playtime. All dumb questions ignored so if I don't respond, you asked a dumb question or made a dumb comment.
We have a choice of 1 custom kernel (Eureka) that can be comprehensively tweaked thanks to many of the settings being moved into the DTB partition. Currently, there are 20 versions of the DTB image that can be selected on kernel installation - 10 enforcing and 10 permissive with 10 different mixes of cpu and gpu frequencies to suit most needs. The default sets everything to maximum and is the cause of the majority of freezing / crashing on an A205 phone that has a lower quality SoC than the other A series compatible phones. Most will end up using DTB2 to fix instability but even this might not be enough. You then have to consider a lower frequency DTB which lessens the attractiveness of using this custom kernel. Why not make your own flavor of DTB that can more accurately reflect what you can run on your specific SoC? Here's how:
Open up the Eureka Kenel zip file in whatever zip extractor you use.
Extract DTB2.img from the zip file (either permissive or enforcing version depending on what your chosen ROM needs)
Now open DTB2.img using a hex editor
Now look at the following which is a list of addresses (in hex), what the value at this address is defining and a list of possible settings. Frequencies are in MHz and the hex code to set it is the frequency in kHz example: 343MHz is 343000kHz, 053BD8 is hex for 343000.
GPU:
5CA5 GPU max freq
5CB5 GPU boost freq
5CC7 GPU boost %load
Possible freqs (MHz):
343 053BD8
450 06DDD0
545 0850E8
676 0A50A0
845 0CE4C8
1001 0F4628
1100 10C8E0
1200 124F80
1300 13D620
CPU smalls:
71B1 CPU min freq
71C1 CPU min freq
71D1 CPU max freq
71E1 CPU max freq
71F1 CPU boost freq
Possible freqs (MHz):
208 032C80
343 053BD8
449 06D9E8
546 0854D0
676 0A50A0
757 0B8D08
839 0CCD58
902 0DC370
1014 0F78F0
1144 1174C0
1248 130B00
1352 14A140
1482 169D10
1586 183350
1690 19C990
1794 1B5030
CPU bigs:
73B9 CPU min freq
73C9 CPU min freq
73D9 CPU max freq
73E9 CPU max freq
73F9 CPU boost freq
Possible freqs (MHz):
208 032C80
312 04C2C0
520 07EF40
728 0B1BC0
936 0E4840
1144 1174C0
1352 14A140
1560 17CDC0
1664 196400
1768 1AFA40
1872 1C9080
1976 1E26C0
2080 1FBD00
2184 215340
2288 22E980
First thing: The default min freq of 208MHz does not save any more battery than setting this to 343MHz (for small cpus) and 312MHz for bigs.
Next thing: The A205 more than likely will become unstable at anything above 2080MHz for the big cpus but can probably cope with 1794MHz on the small cpus. Each SoC is slightly different so you must test what your phone can handle, not what someone else's phone can do!
Next: It is highly unlikely that your A205 will be stable with the GPU maxxing out at 1300MHz. You will not be aware of this until the gpu governor actually cranks the gpu up to that frequency i.e. you can remain oblivious to it for some time and incorrectly assume something else is causing freezes / crashes / glitching.
Next: There are many more settings in the DTB relating to boost frequencies on various input conditions i.e. screen touches, keyboard clicks, mouse clicks etc. Most of these are set to peak at 1144MHz which seems quite reasonable so I have not sought to specifically identify and edit these.
Edit: So here are the input boost frequencies: (address, name, function, freqs)
I assume the first addresses in each block are for BIGS and the 2nd lot are for SMALLS. It seems to work well to set all the BIG freqs to 936 and all the SMALLS to 839 since there is an abundance of upward boosting from other sources such as the Governor and Exynos specific drivers.
50B1 key1 IKEY 1144
5181 key2 ITOUCHKEY 1144
5255 5259 525D 5285 5289 528D key3 ITOUCH 1144 1144 936 839 839 839
5369 536D 5391 5395key4 IMULTITOUCH 1144 936 839 839
545D 5461 5485 5489 key5 IKEYBOARD 1144 936 839 839
554D 5551 5575 5579 key6 IMOUSE 1144 936 839 839
5641 5669 key7 IMOUSE WHEEL 1144 839
5735 5739 575D 5761 key8 IPEN HOVER 1144 936 839 839
5821 5825 5849 584D key9 IPEN 1560 936 839 839
58E5 key10 IKEY_TWO 1872
Recommendations:
Min Freqs:
Set GPU to 343MHz, small CPUs to 343MHz and big CPUs to 312MHz. This is the maximum power saving you will get and offer minimal lag as the frequencies scale up to meet demand.
Set the GPU max freq to 845MHz while you are establishing what is stable for the CPUs.
Set GPU boost to 545 or 676MHz (depending on your compromise between battery and performance)
Set GPU boost load trigger level from the stock 75% down to 50~60%. Again depending on your compromise between battery and performance. Lowering this setting has a significant impact on reducing perceived lag so the stock setting was probably far to high.
Set big CPU max freq down to 2080MHz. This solves most crashing that is due to the cpu being overclocked too far.
Set small CPU max freq to 1794MHz unless your SoC proves to be unstable at this.
Set the CPU boost freqs to something quite low (around 700~900MHz). There are other boosts that override this basic CPU boost freq so you will almost never see it.
Note: If you want maximum battery savings, setting the max freqs lower seems like a logical thing to do but it is not! If you halve the cpu freqs, you double the amount of time they must remain on but you do not halve the power consumption so you end up consuming more power....
Make the changes and save the DTB.img file and flash it in recovery to DTB partition and reboot.
Install hKtweaks_v2.2.2 or your favorite kernel tweaker that can deal with Exynos SoCs (not many can)
Take a look at the cpu and gpu settings to confirm that your edited DTB file is producing the expected results i.e. min and max freqs agree with what you set.
You are done!
Err..... only kidding there is more to do.
Now back to the issue of the GPU max freq. In hKtweaks you can override the settings inherited from the DTB (within the limits set by the DTB). The max GPU freq is also associated with a core voltage. Lowering the voltages will make the GPU run cooler (use less power) but also it will not overclock as far as if the voltage is higher. Here is the dangerous bit - you can increase the voltage to make it overclock higher but cause it to overheat quicker which will make it throttle back to a lower freq. There is also an error in the DTB: Look at the settings for throttling the frequency back at certain temps. Set GPU LEVEL 3 Throttling Freq to 343MHz to fix the error.
Have a play with the GPU settings in hKtweaks without setting Apply on boot so if you set something that crashes the phone, it will revert to normal on a reboot. When you are positive you have the best GPU settings. then set Apply on boot.
Now you are done!
Err..... not quite, there is more.
O.K, assuming you have your custom DTB set up exactly how you want it, it is time to look at some important settings available through hKTweaks.
Firstly we will look at the CPU Governor selection. Interactive is the stock setting and if you watch what the CPU cores are doing with no background activities (kill all unnecessary apps), you will see the frequencies will be dancing around without settling down to the minimum freqs. This is partly due to a dodgy implementation of this governor by Samsung and also the excessive amount of invisible running services that allow Samsung and Google to plunder your personal data in realtime.
Touch the screen, scoll the screen etc. and you will see the various CPU boost features adding to the overall freqs.
The Eureka kernel has extra CPU Governors added - not all function correctly... be warned. Some Governors apply to all CPUs (big and small) and can't be configured separately. Some Governors can have separate configurations for big and smalls.
The way this works is whatever is set for cpu0 is applied to all smalls (cpu0~5) and whatever is set for cpu6 is set for all bigs (cpu6~7).
In a root filemanager, take a look at /sys/devices/system/cpu/cpufreq If you see a folder with the Governor's name, the Governor is applied to all cpus big and small with the same settings. If the Governor does not have a folder here, look in policy0 and policy6 folders. If the Governor has folders in there, the Governor can have separate settings for big and smalls. This is determined by however the Governor was set up at the kernel level.
I can't tell you what Governor is best for your usage patterns - I have already warned you that some are borked so all you can do is try them all while watching their behavior. until you find one that works for you.
Let's use Smartmax as an example. It is not aware of bigs and smalls so any settings are applied to all cpus. If you set this Governor for both big and small cpus, changing the settings in big will change the settings in small as well. The default settings will automatically pick up on the settings you made in your DTB. The remaining settings are not bad as they are but can be improved on.
Try it out, set Smatmax as the governor both both big and small and observe the cpu freqs on idle and when touching / wiggling the screen. You should see it scale up rapidly and scale down to min freqs much better than Interactive was doing. Have a play with other settings if you want - I tend to speed up the ramp down rate and increase the ramp down step to make the cpus return to min freq quicker (for battery saving). Once you have experimented with Smartmax, have a play with the remaining Governors to see if there is anything you like. Something I learnt from a previous phone with a MTK octa core SoC is that there is no power penalty for readily scaling the cpus up to a (sensible) maximum freq. This gives the phone a fast, lag free feel that everyone wants and the cpu will complete its tasks faster so it can return to idle faster. A foolish overclock freq will burn more power - usually when the core voltage is cranked up stupidly high to get the overclock - bad for phone, bad for battery! A bad Governor setup will chew battery if it doesn't pull the frequencies back to idle at low loads but view this in light of the amount of background services you are running. MyAndroidTools is an excellent app to view and take control of pesky services.
The GPU also has a choice of Governors but I recommend sticking with the default Interactive. You get to choose the GPU Highspeed freq and load and both of these settings can be embedded in your DTB. Play with the freq / voltage tables at your own risk!
More to come....
Latest additions:
HMP Settings:
689C 0000020C up threshold
68AC 000000D6 down threshold
68BC 000000FE semiboost_up_threshold
68CC 000000A3 semiboost_down_threshold
68DC 02625A00 bootboost-duration us
68EC 0000001E down_compensation_timeout mS
68FC 0016E360 down_compensation_high_freq uS
690C 000F4240 down_compensation_mid_freq uS
691C 000C3500 down_compensation_low_freq uS
A final note:
If you want to know which CPU, GPU governors are best and what the difference is between them, there is loads of information already gathered on this topic. Most of it is quite dated but still relevant. Here is a good starting point:
[REF][GUIDE]Saber's guide on CPU governors, I/O schedulers and more!
Collective guide of CPU governors, I/O schedulers and other kernel variables I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel...
forum.xda-developers.com
There is a lot of misunderstanding on Eureka Kernel and ROM forums around the issue of memory management - LMK, Virtual Memory etc. Many users want something for nothing like running every known Samsung, Google and Social Media app in the background on a A12.1 or 13 ROM on a phone with 3GB RAM.
The basics of virtual memory have not changed - set ZRAM to no more than 50% of the available memory and set ZSWAP Memory pool to no more than 30%. Swappiness is best at 100% and vfs_cache_pressure set to 50. These settings are the favorite targets for abuse in tweaks offered by people of little knowledge.
Once you have your virtual memory sorted and have made smart decisions on what services/apps you are going to allow to self start on boot and hide in the background, it is a simple case of looking at the free memory to figure out how many more apps can run before killing occurs. It should surprise no-one when it occurs..... blame yourself, not the kernel, not the ROM, but your decisions on what you run and how you configure the phone.......