[Kernel] RenderZenith OP5 [OOS/LineageOS V4.2.0] (22 Mar 2019)

Search This thread

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,084
33
/home/renderbroken/android
Render_Zenith-cropped.png

for OOS and LineageOS OP5/OP5T​

Code:
/*  *** Disclaimer
* I am not responsible for bricked devices, dead SD cards, thermonuclear war, 
* or you getting fired because the alarm app failed. Please do some research 
* if you have any concerns about features included in this KERNEL
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
* BOOM goes the Dynamite
*/

This kernel is a joint collaboration between @joshuous and myself. Our primary goal is to deliver a fast, smooth and stable kernel with Energy Aware Scheduling (EAS). We have spent countless hours backporting, experimenting, tuning and improving our understanding of EAS in our kernels. We aim to keep our kernel slim on features, adding only what we believe is essential.

It is also our desire to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.


Features:
* Energy Aware Scheduler enabled
* Dynamic Stune Boost


Kernel Downloads:
Latest OOS Build (Magisk required for ramdisk changes to apply!)
Latest LineageOS 16.0 Build

Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything! At least backup BOOT via TWRP
* If you're not coming from completely stock kernel, please dirty flash your stock ROM first
* Flash kernel zip
* Flash Magisk (compulsory only for OOS build to get ramdisk changes working!)
* Reboot


Reporting Bugs (please read):
* Make sure you're not using any tweak apps (Greenify, Naptime, anything else related), otherwise no support will be given. If you have an issue, disable all your tweaks first and see if that fixes your problem. Otherwise, flash the stock kernel and see if you can reproduce it as well.
* If you previously flashed another kernel, make sure you dirty flashed the full ROM zip before flashing RenderZenith kernel.
* Logs! Please provide dmesg kernel logs via Syslog app. If you experienced a kernel panic (system crash/reboot) please provide all ramoops file in /sys/fs/pstore/


THANKS!!!!
* The kind people who keep this project alive
* Everyone who supported us throughout our projects
* @joshuous for his partnership and collaboration with our current projects and many more to come. The future looks bright!


Source Links:
https://github.com/EAS-Project/op5-kernel/commits/master
https://github.com/EAS-Project/op5-kernel/commits/lineage-16.0-master
https://github.com/EAS-Project/AnyKernel2


EAS writeups:
Dynamic Stune Boosting
PELT and WALT



XDA:DevDB Information
[Kernel] RenderZenith OP5 [OOS/LineageOS V4.2.0] (22 Mar 2019), Kernel for the OnePlus 5

Contributors
RenderBroken, joshuous
Kernel Special Features: Energy Aware Scheduling

Version Information
Status: Testing

Created 2017-08-21
Last Updated 2019-03-22
 
Last edited:

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,084
33
/home/renderbroken/android
For Devs that are interested in porting EAS:

Hey guys! We took all the EAS commits that make up RenderZenith and pulled them into their own repo. This will allow those interested to port our EAS work into their own projects! Note that you may have to adjust the Energy Model commit to fit your project.

Source:
https://github.com/EAS-Project/op5-oreo-kernel/tree/eas-commits
 
Last edited:

joshuous

Recognized Developer
Jun 7, 2015
1,155
5,598
Wait what is the difference between RenderKernel and RenderZenith?

Hi I'm the developer of Zenith EAS Kernel, which eventually was renamed to RenderZenith kernel as a sign of my deepest respect to @RenderBroken for his tireless work on bringing up the EAS base on MSM 3.18 kernels. We've been working closely together since many moons ago to pioneer the first fully fledged EAS ROM on a non-Pixel device (OP3). He was a mentor to me when I began kernel development a few months back. We shared common goals for what we wanted to see in a kernel, and recently discussed merging our work so that we can focus on different aspects of the kernel and bring our findings together. We decided to use the existing RenderZenith name for our new joint project as a sign of our collaboration
 

Zocker1304

Senior Member
Feb 15, 2016
787
281
Hi I'm the developer of Zenith EAS Kernel, which eventually was renamed to RenderZenith kernel as a sign of my deepest respect to @RenderBroken for his tireless work on bringing up the EAS base on MSM 3.18 kernels. We've been working closely together since many moons ago to pioneer the first fully fledged EAS ROM on a non-Pixel device (OP3). He was a mentor to me when I began kernel development a few months back. We shared common goals for what we wanted to see in a kernel, and recently discussed merging our work so that we can focus on different aspects of the kernel and bring our findings together. We decided to use the existing RenderZenith name for our new joint project as a sign of our collaboration
Nice to hear, so this is the new, ultimate EAS kernel?
 
  • Like
Reactions: RenderBroken

azzio4675

Senior Member
Jul 12, 2015
100
5
Hi I'm the developer of Zenith EAS Kernel, which eventually was renamed to RenderZenith kernel as a sign of my deepest respect to @RenderBroken for his tireless work on bringing up the EAS base on MSM 3.18 kernels. We've been working closely together since many moons ago to pioneer the first fully fledged EAS ROM on a non-Pixel device (OP3). He was a mentor to me when I began kernel development a few months back. We shared common goals for what we wanted to see in a kernel, and recently discussed merging our work so that we can focus on different aspects of the kernel and bring our findings together. We decided to use the existing RenderZenith name for our new joint project as a sign of our collaboration

will you make vertex os for op5?
 

Logi_Ca1

Senior Member
Jun 29, 2011
475
98
For some reason, installing this disables my WiFi permanently. I had to flash the whole OOS package to get it back, flashing the stock kernel didn't work. Anyone else encountered this? For what it's worth, I don't have a SIM card in my OP5 yet.
 

Stupifier

Senior Member
Jun 8, 2010
1,906
680
For some reason, installing this disables my WiFi permanently. I had to flash the whole OOS package to get it back, flashing the stock kernel didn't work. Anyone else encountered this? For what it's worth, I don't have a SIM card in my OP5 yet.

Woah....definitely have not experience that problem. No issues to report so far for me. Been using it for about 16 hours now.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 89
    Render_Zenith-cropped.png

    for OOS and LineageOS OP5/OP5T​

    Code:
    /*  *** Disclaimer
    * I am not responsible for bricked devices, dead SD cards, thermonuclear war, 
    * or you getting fired because the alarm app failed. Please do some research 
    * if you have any concerns about features included in this KERNEL
    * before flashing it! YOU are choosing to make these modifications, and if
    * you point the finger at me for messing up your device, I will laugh at you.
    * BOOM goes the Dynamite
    */

    This kernel is a joint collaboration between @joshuous and myself. Our primary goal is to deliver a fast, smooth and stable kernel with Energy Aware Scheduling (EAS). We have spent countless hours backporting, experimenting, tuning and improving our understanding of EAS in our kernels. We aim to keep our kernel slim on features, adding only what we believe is essential.

    It is also our desire to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.


    Features:
    * Energy Aware Scheduler enabled
    * Dynamic Stune Boost


    Kernel Downloads:
    Latest OOS Build (Magisk required for ramdisk changes to apply!)
    Latest LineageOS 16.0 Build

    Instructions:
    * Boot into Recovery
    * (Recommended) Make a complete backup of everything! At least backup BOOT via TWRP
    * If you're not coming from completely stock kernel, please dirty flash your stock ROM first
    * Flash kernel zip
    * Flash Magisk (compulsory only for OOS build to get ramdisk changes working!)
    * Reboot


    Reporting Bugs (please read):
    * Make sure you're not using any tweak apps (Greenify, Naptime, anything else related), otherwise no support will be given. If you have an issue, disable all your tweaks first and see if that fixes your problem. Otherwise, flash the stock kernel and see if you can reproduce it as well.
    * If you previously flashed another kernel, make sure you dirty flashed the full ROM zip before flashing RenderZenith kernel.
    * Logs! Please provide dmesg kernel logs via Syslog app. If you experienced a kernel panic (system crash/reboot) please provide all ramoops file in /sys/fs/pstore/


    THANKS!!!!
    * The kind people who keep this project alive
    * Everyone who supported us throughout our projects
    * @joshuous for his partnership and collaboration with our current projects and many more to come. The future looks bright!


    Source Links:
    https://github.com/EAS-Project/op5-kernel/commits/master
    https://github.com/EAS-Project/op5-kernel/commits/lineage-16.0-master
    https://github.com/EAS-Project/AnyKernel2


    EAS writeups:
    Dynamic Stune Boosting
    PELT and WALT



    XDA:DevDB Information
    [Kernel] RenderZenith OP5 [OOS/LineageOS V4.2.0] (22 Mar 2019), Kernel for the OnePlus 5

    Contributors
    RenderBroken, joshuous
    Kernel Special Features: Energy Aware Scheduling

    Version Information
    Status: Testing

    Created 2017-08-21
    Last Updated 2019-03-22
    74
    I wrote a new feature in the latest kernel and have been testing it for over a week. It's called Dynamic Stune Boost.
    For those who are not sure what Stune (schedtune) boosting is, it is an EAS feature that allows you to bias frequencies higher or lower for certain task groups.
    Android defines the following task groups that you can boost:

    1. Top-app: The task that you're directly working on, or the task that you see. This mostly refers to the app that you're currently interacting with.
    2. Foreground: Tasks that are not the top-app, but are still part of the user experience (e.g. the surfaceflinger display thread and audio threads)
    3. Background: Tasks that are not part of the user experience (e.g. some random task running in the background that you don't care about)
    4. System-background: Similar to background, but specifically for system tasks
    5. Root: anything that else that does not belong to the other categories

    Why do we need Schedtune boosting when we already have the cpu-boost feature?
    cpu-boost works by allowing the user to set the specific boost frequencies and duration for clusters. But how do you know whether the frequency you specified is too little or too much? If you specify 1000 MHz boost for Little cluster, is that overkill for typing, or is it too miniscule for scrolling in a content-heavy app like Google Calendar? You end up facing a dilemma of choosing between increased battery drain or increased smoothness. Personally, I find that cpu-boost is rather inflexible and doesn't scale according to the user's needs.

    So how does Schedtune boosting work?
    Let's first talk about Schedutil governor. It works by using utilisation data provided by the [Linux] Completely Fair Scheduler. The 'CFS Scheduler' (not I/O scheduler erherm), in simple words, decides which tasks should be assigned to which CPU cores. Based on the Scheduler's knowledge of the tasks it allocates to cores, it can directly sends signals about the cores' utilisation to the Schedutil governor. Think of utilisation as the number of customers that a chef needs to serve at this point in time. The Schedutil governor uses the utilisation value and tells the chef how fast he must cook (what frequency the core should run at).

    Now sometimes you may have certain customers (who are part of the Top-App Company) who are in a hurry to get their food and rush back to work. You need to serve the Top-App customers urgently, so you ask the chef to cook even faster than usual. You can think of Schedtune boosting as artificially inflating the number of customers (boosting the utilisation value) to get your chef to cook faster.

    The beauty of Schedtune boosting over cpu-boost is that you don't need to fix a frequency to boost to. Instead, the Schedutil governor will give certain tasks a little bit more oomph. If the original unboosted frequency for scrolling is 600 MHz, Schedutil may boost it a little bit more to 750 MHz, for example. If the unboosted frequency for scrolling in calendar is 1000 MHz, perhaps Schedutil may boost it to 1300 MHz. It all depends on the boost value you want to set.

    Give Schedtune boosting a go
    Analogies aside, you can adjust the boost value in /dev/stune/{top-app, foreground, background, system-background}/schedtune.boost. Usually we mostly care about boosting top-app. Schedtune boost basically boosts the utilisation value by a certain factor. For example, if you set a boost value of 10, the utilisation (not the frequency) is boosted by 10%. A larger utilisation value will cause Schedutil to select a higher frequency.

    Try setting the value in /dev/stune/top-app/schedtune.boost to a value between 10-20. Turn off cpu-boost. Enable GPU profile rendering and watch the magic. If your results are like mine, you'll see very low bars which means that it's really smooth. Launch CPU Float app and observe the frequencies. You might notice that they run at a very low frequency compared to the default cpu-boost value, yet it is even smoother. Why is Schedtune boosting producing smoother experience at a lower frequency? I have no freaking clue :S. (EDIT: I know why now. It biases tasks to the Big cluster).

    Now what is Dynamic Schedtune Boosting?
    The issue with setting schedtune boosting (in /dev/stune/*) is that it boosts 24/7 and could drain a bit more battery. There are some situations when you may not want to boost, such as watching YouTube (Top-app task). Boosting is beneficial for mostly touch activity, such as scrolling or typing. The solution I implemented was extending the cpu-boost feature to apply schedtune boost only during touch activities. Other than touch events, schedtune boost won't run 24/7 and drain excess battery.

    Getting started with Dynamic Stune Boost
    To get started do the following:
    1. Enable cpu-boost
    2. Set all cpu-boost frequencies to zero
    3. Set the boost duration to 1500ms (you can vary it depending on your needs)
    4. Edit the boost value in /sys/module/cpu_boost/parameters/dynamic_stune_boost to between 10-20. Feel free to adjust this value. Make sure to set /dev/stune/top-app/schedtune.boost to 0, otherwise it may overwrite dynamic schedtune boost.
    5. Turn on GPU Profile Rendering to analyse smoothness of frames.
    6. Enjoy and report back your findings in terms of your tunable values, smoothness and battery drain.

    tldr; If your brain hurts, just follow the instructions in "Getting started with Dynamic Stune Boost"
    67
    EAS RZ-3.0.0 for OxygenOS release!

    Sorry it took quite a while. I had EAS up and running since 20 Dec, but had inspiration for other performance improvements, and real life was happening for @RenderBroken and me. The wait is now over!

    Instructions (IMPORTANT!)
    - Dirty flash OOS before coming from another kernel
    - Dirty flash OOS before switching to another kernel

    What's in?
    - EAS for msm-4.4
    - Westwood TCP congestion algorithm (default)
    - CFQ (default)
    - Schedutil (default)
    - Compatible with stock CAF performance framework
    - WALT load tracking (default)
    - Upstreamed to Linux 4.4.114
    - Upstreamed to CAF 6.4.6100
    - Dynamic Stune Boost v3 (proper top-app detection)
    - Minimum freq set to 300MHz on Little and Big. We're currently evaluating the impact of CAF's new higher default min freqs.
    - Compiled with GCC 6.4

    FAQs
    1. Is it...?
    Yes, it's unified. All new OOS kernels are unified by default.

    2. Notification delays over wifi?
    I believe I have fixed it. Please confirm with me if you still face issues with this.

    3. What ROM does this work on?
    OOS Oreo only for now. I test my kernels on the latest stable release.

    4. What about the missing features that were present in Nougat kernel?
    We'll bring these features back in future releases.

    Bug reporting
    As always, proper bug reporting etiquette includes the following:
    1. Logs (dmesg / ramoops). You may use Syslog app to collect.
    2. A description of the problem and how to reproduce it (if possible)
    3. Confirm that you have tried dirty flashing OOS followed by RenderZenith kernel again, and that you still experience the bug.

    Let us know how the kernel works for you! :cowboy:

    DOWNLOAD

    SOURCES
    64
    RenderZenith for OOS-N: V2.0.0 is here!!!

    Things to note:
    This will be a major release
    Update to EAS 1.4
    Pulled in assorted EAS/CAF changes (Outside Official EAS Versions)
    Updated OOS Code to: 4.5.14
    Updated Low Power Mode (Better Sleep)
    Updated Bluetooth drivers
    Rolled back LowMemoryKiller to ACK 4.4
    Many more!

    Download

    Changelog

    PS: It was nice to see that The EAS work Josh and I have been doing is much more advanced than the EAS work used on the Pixel 2. I would imagine that we will stay on the forefront of EAS Kernel Development as long as the changes are stable enough for our standard. Currently, the Pixel 2 is using a blend of EAS 1.2 and some EAS 1.3. We are now using EAS 1.4! There have been MAJOR changes on the EAS front and between CAF and EAS. We look forward to bringing the best to RenderZenith and to our other projects.

    Also, I would like to take the time to thank @bluh5d for his help with getting us the Pixel 2 information we needed to progress our EAS work.
    46
    For Devs that are interested in porting EAS:

    Hey guys! We took all the EAS commits that make up RenderZenith and pulled them into their own repo. This will allow those interested to port our EAS work into their own projects! Note that you may have to adjust the Energy Model commit to fit your project.

    Source:
    https://github.com/EAS-Project/op5-oreo-kernel/tree/eas-commits