Related
I take no credit of these codes. All i did is create a patch against with the leo kernel tree.
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Click to expand...
Click to collapse
2.6.32-sched-bfs-318.patch.zip: is the patch is downloaded from official BFS site.
oc_uv_ab.patch.zip : this patch includes under volt, overclocking (upto 1.3GHz, any frequency above 1.15G is unstable on some of HD2s) and audio boost.
how does it work?
Sounds great. Maybe someone can integrate this into a kernel?
thanks for this!!
How to apply patch
I could really use the audio boost. Is there anyway you could explain how to apply the patches. Or is it possible you could apply them and post the patched kernel files? Thanks.
Would this actually have an improving effect on the touchscreen being unresponsive from time to time?
Hello,
Would it be possible to add the newer versions for oc_uv_ab.patch and interactive governor or I just don't know how to use GIT to well?
I don't have too much experience with C++, PHP dev here , and I'd like to compile my own kernel from the official GIT + change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
dlsniper said:
change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
Click to expand...
Click to collapse
This would be great.If someone can guide us how to make our wifi mac address
dolby71 said:
how does it work?
Click to expand...
Click to collapse
Just sit down and relaxed lol,michelle (michyprima kernel) or the topic starter build them i guess in few days
Whoops,nevermind,old topic i see
This will allow you to load unsigned kernel modules. These kernel modules are now compatible with OC1 AND OF1!
Devs do not use my work without permission!
Do not deviate from the instructions or try to use any other kernel modules unless you know what you are doing.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Flash the downloaded zip in FlashFire or Safestrap:
OC1
https://www.androidfilehost.com/?fid=24459283995307174
OF1
https://www.androidfilehost.com/?fid=24459283995307172
Credits:
This is completely based off of @jeboo's original BypassLKM exploit on MK2.
Modload script updated by @Surge1223
@stang5litre for helping with my late night screwups.
@npjohnson for helping me get my start on this.
@bkkzak and @mugsy77 for OF1 testing
@Edgardo_Uchiha for the startup script suggestion
Kernel modules compiled and tested by myself and all mdk users on my AIO kernel
These are the exact same modules that mdk users have.
Some are not there right now but I am working towards getting more added.
CPU GovernorsAbyssplug:
Abyssplug governor is a modified hotplug governor.
Alucard
A favourite 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.
ArterActive
It is an interactive CPU governor port from newer source code. It has more optimizations for Snapdragon 80x processors.
ConservativeX
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
IntelliActive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
Created by Faux
IntelliDemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
IntelliMM
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.
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.
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.
OndemandPlus
Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.
Optimax
This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative.
It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life
PegasusQ
The Pegasusq 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.
Smartmax
Smartmax is a mix between ondemand and smartassv2. It behaves mostly like smartass with the concept of an "ideal" frequency. 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:
in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice.
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.
Post3:
IO SchedulersIO Scheduler Comparison
Overall performance:
Best<------------------------------------------------------------------------->Worst
FIOPS > Noop > ZEN > Tripndroid > SIO > SIOplus > VR > Deadline > CFQ
Multitasking performance:
Less Apps<------------------------------------------------------------>Many Apps
Noop < FIFO < FIOPS < SIO < SIOplus < Tripndroid < ZEN < Deadline < VR < CFQ
Battery life:
Best<-------------------------------------------------------------------------> Worst
Noop > FIFO > FIOPS > SIO > SIOplus > ZEN > Tripndroid > Deadline > VR > CFQ
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.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
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) exhibited can sometimes be high, because of the number of tasks competing for the disk.
Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
FIFO (First in First Out):
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.
Benefits:
- Serves I/O requests with least number of cpu cycles.
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not very good at multitasking
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
- Good battery life
Disadvantages:
- Not very common in most kernels
- Not the most responsive IO scheduler (Can make phone lag)
- Not good at heavy multitasking
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.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
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
- Not found in all kernels
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:
- Not found in all kernels
- Performance varies between different devices (Some devices perform really well)
VR
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
ZEN:
ZEN scheduler is based on the VR Scheduler. 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 no-op blended with VR features.
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)
- Not found in all kernels
Woot congrats @klabit87 they should love this!!!!
Sent from my stang5litre Edition 5.0 v3
second.......
gj
klabit87 said:
Reserved
Click to expand...
Click to collapse
Congrats my man! Know this was a long time coming for you.
@klabit87
Thanks man!
So what options does this enable that previously weren't available? And do you have a kernel auditor profile that you would care to share (that way settings can be applied more easily)?
bkkzak said:
@klabit87
Thanks man!
So what options does this enable that previously weren't available? And do you have a kernel auditor profile that you would care to share (that way settings can be applied more easily)?
Click to expand...
Click to collapse
This is not my daily device so I can't really tell you exactly what settings will work well but I'm sure a few more people will be able to post what works well for them.
It enables cpu governors that will help with battery life and performance. Some are just for performance so there may be a dip in battery life if they are used.
Others are made for battery conservation. There are descriptions in my aio kernel thread. I will update this thread to reflect them soon.
Can i flash this thru stock recovery or flashfire?
bontiloi said:
Can i flash this thru stock recovery or flashfire?
Click to expand...
Click to collapse
Flashfire. I will correct that soon as I can
Post 2 has been updated with descriptions of the different cpu governors and IOschedulers.
I do plan to add more as time permits. These should be plenty for you guys to use and get accustomed to custom governors.
So locked bl users have the same functionality of a custom kernel.
klabit87 said:
This is not my daily device so I can't really tell you exactly what settings will work well but I'm sure a few more people will be able to post what works well for them.
It enables cpu governors that will help with battery life and performance. Some are just for performance so there may be a dip in battery life if they are used.
Others are made for battery conservation. There are descriptions in my aio kernel thread. I will update this thread to reflect them soon.
Click to expand...
Click to collapse
Thanks!
So I noticed a bit of a problem but didn't have a whole bunch of time to test. I flashed followed your instructions exactly (flashing in newest safestrap with TWRP 3.0.0) and it works great. Then I decided to uninstall Safestrap (so I don't get the annoying pre-boot screen), BUT I couldn't load Safestrap app - it kept force closing. So I tried using your NC5 flasher to flash NC5 kernel, it seemed to work fine and I hit reboot in the app. Then when rebooting I hit 'recovery' on the SS screen and it booted into the rom... So obviously NC5 kernel was never flashed and this makes me think that once these kernel modules have been applied, then another kernel can't be flashed?
I'm not sure if anyone else has experienced this but just wanted to bring it to your attention. S4 is no longer my daily driver (N6P now) but I still use it as a media device.
bkkzak said:
Thanks!
So I noticed a bit of a problem but didn't have a whole bunch of time to test. I flashed followed your instructions exactly (flashing in newest safestrap with TWRP 3.0.0) and it works great. Then I decided to uninstall Safestrap (so I don't get the annoying pre-boot screen), BUT I couldn't load Safestrap app - it kept force closing. So I tried using your NC5 flasher to flash NC5 kernel, it seemed to work fine and I hit reboot in the app. Then when rebooting I hit 'recovery' on the SS screen and it booted into the rom... So obviously NC5 kernel was never flashed and this makes me think that once these kernel modules have been applied, then another kernel can't be flashed?
I'm not sure if anyone else has experienced this but just wanted to bring it to your attention. S4 is no longer my daily driver (N6P now) but I still use it as a media device.
Click to expand...
Click to collapse
Ok thanks. I will look into that. Until then might be best to use flashfire.
I would rather use flashfire and have custom kernel modules than use ss. But I will see what I can do.
Thanks
klabit87 said:
Ok thanks. I will look into that. Until then might be best to use flashfire.
I would rather use flashfire and have custom kernel modules than use ss. But I will see what I can do.
Thanks
Click to expand...
Click to collapse
For now, how do I revert the kernel mods so that I can flash NC5 Kernel, uninstall safestrap, then re-flash kernel mods with FlashFire?
bkkzak said:
For now, how do I revert the kernel mods so that I can flash NC5 Kernel, uninstall safestrap, then re-flash kernel mods with FlashFire?
Click to expand...
Click to collapse
Whether you flash with ss or ff isn't the issue. It's the script. You need to remove the config to start the script in smanager on startup. There is an error in the module loading. I will be fixing that this evening.
klabit87 said:
Whether you flash with ss or ff isn't the issue. It's the script. You need to remove the config to start the script in smanager on startup. There is an error in the module loading. I will be fixing that this evening.
Click to expand...
Click to collapse
Ok; so if I just go into smanager, tap on modload then deselect start on boot and hit save, then reboot, I should be able to load safestrap app and uninstall the bootstrap?
bkkzak said:
Ok; so if I just go into smanager, tap on modload then deselect start on boot and hit save, then reboot, I should be able to load safestrap app and uninstall the bootstrap?
Click to expand...
Click to collapse
Yes. Because then there is nothing to interfere with the kernel memory.
If not let me know because I have another theory. Thanks.
It worked for me in testing but now I do see your issue.
It has been fixed. @bkkzak Go to your busybox app and select install in order to re-install busybox.
Somehow it got borked. But the zip is fixed now. no need to reflash. Just reinstall busybox and all will be fixed.
Sorry for the mess up guys.
Took the plunge last night since I can never leave anything be. I'm running stangs ROM with these modules and love it! Followed directions, flashed with FF and not a problem. Been using app you suggested for tweaking but may look for one with profiles. Thanks again, its like a new toy. Just surprised the page is getting plenty of views but very few downloads of the module or comments... Great work..!
Working great so far. Using darkness gov as it seems to hover on 1 core more than others a hotplugs faster. Looking forward to seeing more all of them added. Thanks!!
Absolutely brilliant work @klabit87! Can't wait to flash this up and tweak. Is our Safestrap v4.01-B02 functional to flash this or does the patch still need to be implemented? I'll use FlashFire if not, probably use FF anyways since I saw a confirmation above.
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 , more on that later in the second post), 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, validus, tipsy, and tesla. It is based off of the lineage kernel with tons of improvements from @darkobas's amazing omni kernel, I do my best to keep it up to date with omni and lineage
Downloads
regular build (for every rom but omni)
regular build for omni
Note, I cannot support every ROM out there, doing that would take too much time, here are ROMs that are known to have issues with my kernel and thus are not supported
1. Paranoid Android
2. JUI
In order for these ROMs to work you will have to modify the ramdisk
Install instructions:
In twrp go to the install page, in the bottom right corner select "install image", select the desired kernel, then select "boot", then swipe to flash, then go back to the install screen and install magisk or SuperSU if you don't want to lose root, and then reboot
Here are some of the features
(check out the third, and fourth posts for more info)
f2fs is supported- majority credit to darkobas
eas, credit to lineage
CPU:
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
sched governor
schedutil 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
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
Read the second, third, and fourth posts for more info on the kernel settings, and features, and how to get better performance and battery life and stuff like that
Some screenshots
Thanks to:
darkobas and lineage for the amazing base and continued work on it
Sultan
Franco
dabug123
GalaticStryder
The Flash
There are many more
Source:
Nougat builds:
https://github.com/AICP/kernel_leeco_msm8996/tree/n7.1
Oreo builds:
https://github.com/AICP/kernel_leeco_msm8996/tree/o8.0
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. Underclock the big cores to 1900mhz
2. Set the GPU governor to simple_ondemand
3. Set the vibration strength to zero (or close to zero) in the misc section
4. Set the default I/O scheduler to noop
5. 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)
6. Use greenify to enable aggressive doze and doze on the go, and use it to limit background apps
7. 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
8. Turn off all animations in developer options
9. In kernel adiutor set the low memory killer values to the aggressive setting
10. Disable fsync (risky, you could lose data if the system crashes)
==================================================================================================================================================================================================================
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. Turn off all animations in developer options
4. Overclock the little cores to 2188mhz, and the big cores to 2342mhz
5. Disable fsync (risky, you could lose data if the system crashes)
6. Enable ksm, and use zram for more free ram, good for gaming
7. Set the CPU governor to wheatley
Kernel Info
Here is some info on my Kernel builds
Brief overview:
Regular builds (Included in some roms)- based on Lineage (with many improvements from Omni), This has eas, so don't use the interactive cpu governor.
the one for omni is the same except the ramdisk has been optimized for omni so it will boot on it
Info on kernel settings:
CPU governors (the recommended ones), 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:
don't use this, terrible on eas
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.
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.
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 schedutil for everyday usage, wheatley for performance. and Impluse 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/n7.1/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://sites.google.com/site/easylinuxtipsproject/speed#TOC-Only-768-MB-RAM-or-less:-enable-zRam
zRam creates a compressed swap file in your RAM. The compression factor is the gain: with that, you "increase" your RAM.
The price you pay for this, is:
- Your processor (CPU) is being taxed more heavily, because it'll have to compress and decompress all the time;.
That's why, I advise zRam only for phones with very little RAM (Not zl1), and even then only in combination with a swappiness that has been decreased to 5.
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.
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 stability and don't mind losses in performance, and latency, and stuff like that
Good job ,
Now I'm on omni , work without any problem
If u can make one for eui this will be great
Thanks! This thread will be useful for all of us!
Good job? Thanks??
BlackScreen-eas_4-23-17 on RR f2fs OK
BlackScreen_4-23-17 on RR f2fs OK (liveDisplsy Ok)
Inviato dal mio LEX720 utilizzando Tapatalk
Very nice. Which one would you recommend for Ground Zero's Tipsy ROM, which is based on Slim?
benjmiester said:
Very nice. Which one would you recommend for Ground Zero's Tipsy ROM, which is based on Slim?
Click to expand...
Click to collapse
I used both and didn't work, but previous version, I have to try these new versions
Just flashed it with lineage actual release. Many many thanks. Its finally usable!
Great work. Please keep it up.
Performance/Battery is amazing
So Yesterday i flashed BlackScreen_4-23-17 (Los14.1), today i wanted to test Game performance = Battery usage
and i must say that the Result are Really nice so let me start off by saying thank you for this amazing kernel, it made it possible to play games on Los 14.1 without stuttering.
I roughly played 4 hours and still have 46% this includes Chrome,games,Youtube and benchmarks etc. but see it for yourself i did some screenshots of System monitor and BetterBatteryStats i dont know if you can read the BetterBatteryStats.txt but i figured i add it aswell.
I also followed your guide on Reaching better Performance if that helps.
benjmiester said:
Very nice. Which one would you recommend for Ground Zero's Tipsy ROM, which is based on Slim?
Click to expand...
Click to collapse
It's already included in tipsy...
hello, what is settings by default without root and no use Kernel auditor ?
thx thx
I made a mistake. I flash the image of the kernel onto the image twrp recovery. Now I have no recovery and no root. How do I put twrp in into recovery without a computer
Sent from my LEX727 using XDA-Developers Legacy app
toanau said:
I made a mistake. I flash the image of the kernel onto the image twrp recovery. Now I have no recovery and no root. How do I put twrp in into recovery without a computer
Click to expand...
Click to collapse
But into fastboot mode and then install the twrp Img again using adb tools on your computer
Hi mosimchah first of all congratulations for the great work you are carrying on. I'm currently testing the regular kernel and noticed the new up_threshold and down_thresold settings on the CPU board. I tried in op but did not find anything about it. If I understand that the use of these new parameters should serve to turn on and off the second small cluster core in relation to the load of the root core. right? I think with this new implementation you will have a good battery saver. You could better explain how this feature works and how to configure it best. Thanks for the great work??
Inviato dal mio LEX720 utilizzando Tapatalk
N1m0Y said:
Hi mosimchah first of all congratulations for the great work you are carrying on. I'm currently testing the regular kernel and noticed the new up_threshold and down_thresold settings on the CPU board. I tried in op but did not find anything about it. If I understand that the use of these new parameters should serve to turn on and off the second small cluster core in relation to the load of the root core. right? I think with this new implementation you will have a good battery saver. You could better explain how this feature works and how to configure it best. Thanks for the great work??
Inviato dal mio LEX720 utilizzando Tapatalk
Click to expand...
Click to collapse
Not sure what you're referring too, can you screenshot it
Thanks for sharing this! Do you have any idea if Double Tap to Wake can be added?
Overstew said:
Thanks for sharing this! Do you have any idea if Double Tap to Wake can be added?
Click to expand...
Click to collapse
Yes it will be added soon, the lineage team is working on an implementation of it.
mosimchah said:
Not sure what you're referring too, can you screenshot it
Click to expand...
Click to collapse
Up_threshold and down_thresold???
Inviato dal mio LEX720 utilizzando Tapatalk
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?