[Kernel] RenderZenith OP3/T [OOS-O-EAS-V1.3.0][25 Oct 2018]

Search This thread

uzumakivishal96

Senior Member
Apr 29, 2018
59
3
OnePlus 6
Xiaomi Poco F1
Sir, when I installed the kernel by dirty flashing and then rebooting my handset then it is always bootlooping please look into the issue. I rebooted my one plus 3t due to installing the magical module and updating the substrate theme
 

tofuboi01

Senior Member
Oct 29, 2010
465
138
United Kingdom
Sir, when I installed the kernel by dirty flashing and then rebooting my handset then it is always bootlooping please look into the issue. I rebooted my one plus 3t due to installing the magical module and updating the substrate theme

I find substratum to cause bootloops and now steer clear of using such themese, especially doing any dirty flashing of ROM/Kernel related.
 

uzumakivishal96

Senior Member
Apr 29, 2018
59
3
OnePlus 6
Xiaomi Poco F1
I did it but I found that installing magical 17.1 is making boot loop

---------- Post added at 01:34 AM ---------- Previous post was at 01:30 AM ----------

I did it but I found that installing magisk17.1 is making boot loop I uninstalled all the substratum themes
 

xuser_

Senior Member
Nov 13, 2016
756
131
I'm working on AOSPA in my spare time. The reason I put VertexOS on hold was mostly due to lack of time, and computing resources being a bit more limited

Thanks <3
Would love to try PURE AOSPA EAS <3
Not the best option for devs like you and you might already know it but how about free trial cloud(google/aws etc..) account? :)
 

daywiz

Member
Jun 1, 2017
35
33
RenderZenith v1.2.0 release for OOS!

More delayed than I hope it would be, but here you go!

Changes:
  • Upstreamed to Linux 3.18.122
  • More performance-oriented SchedTune boost changes
  • Added USB Fast Charging feature (charges at 900mA instead of 500mA on supported connections). Use at your own risk. Toggle via /sys/kernel/fast_charge/force_fast_charge

Download
RZ-OP3-OOS-1.2.0-180910-80c6d0c2.zip

Does it require a dirty flash of the ROM before flashing the new version of the kernel?
 

rdNNNN

Senior Member
Dec 21, 2014
93
87
I'm having an old issue. When using your kernel, it seems a lot of work gets scheduled in core0.
For instance, when I restart my phone, that core gets stuck with 100% cpu usage for some minutes until the system settles. When I use the stock kernel the workloads get spread on all cores (~100% usage on all cores) and the system "finishes" booting much faster, I mean, it "settles" quicker. Hope that I made sense in that description.
It happened in 1.2.0, now happens with 1.3.0. I even tried a full phone wipe plus stock OSS reflash to see if it would get rid of it. Nothing, the same behaviour.
I don't know if you can reproduce this. Mind you, I'm using 5.0.6 OOS with latest magisk.
 
  • Like
Reactions: Bintang Krisna

chinmai560621

Senior Member
Mar 11, 2016
243
134
I'm having an old issue. When using your kernel, it seems a lot of work gets scheduled in core0.
For instance, when I restart my phone, that core gets stuck with 100% cpu usage for some minutes until the system settles. When I use the stock kernel the workloads get spread on all cores (~100% usage on all cores) and the system "finishes" booting much faster, I mean, it "settles" quicker. Hope that I made sense in that description.
It happened in 1.2.0, now happens with 1.3.0. I even tried a full phone wipe plus stock OSS reflash to see if it would get rid of it. Nothing, the same behaviour.
I don't know if you can reproduce this. Mind you, I'm using 5.0.6 OOS with latest magisk.

Higher the top-app/ shedtune.boost value, more is the bias to place the task on the big core

Try changing the dynamic stune boost and shedtune.shed_boost for top app to 50 and the CPU input boost to 1ghz on both for ~500ms . This might mean faster task completion and consequently cpuidle is reached faster . This should address your concern of load being distributed evenly and finishing things faster.. BUT this will also mean that your little cores will max out and thus you might face higher battery drain.

Unrelated to the reply,
EAS and it's scheduling seems to be more effective on octa-core systems than quad core systems. Thanks to the higher core count, more cores are available for the tasks to be placed on . Task placement is now more even and proper. Higher levels of smoothness can be achieved, while still not compromising on battery. It seems like we cannot reap the complete benefits of eas given a quad core system. We also should remember that this implementation of eas is not complete(we do use bits of HMP to get things going) and moreover our batteries must have degraded a lot.

Things MIGHT be more balanced , better on the stock HMP kernel but I seem to come back here because of the extremely consistent smoothness this kernel offers which most of the setups cannot offer .. I'm ready to compromise SOT and other things for this butter. In the end it all depends on what you want.

I came to this conclusion after endlessly searching for better optimised ROMs and kernels, and pestering
@joshuous with countless questions.
 
Last edited:

twoxa

Senior Member
Jun 10, 2009
1,550
465
Boston
Nice and smooth here but doesn't this kernel support full screen calibration?..... Via kernel auditor for example.... That's strange.
 

Bintang Krisna

Senior Member
Dec 23, 2016
148
32
Im getting around 20-30% battery drain per hour for just only browsing,YouTube,NO gaming.
Whats wrong? I dont use Greenify,Naptime bla bla bla

What log do i need to provide?
Thank you,any replies is appreciated


Sent from my OnePlus 3 using XDA Labs
 

Bintang Krisna

Senior Member
Dec 23, 2016
148
32
my problem is solved i think,the kernel needs to adapt with the device maybe,now im getting only 20% per hours nothing more than that :)

Sent from my OnePlus 3 using XDA Labs
 
  • Like
Reactions: joshuous

Top Liked Posts

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

    for OOS-O​

    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 time 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 Scheduling (EAS) backported from Android Common Kernel 4.4
    * Many backported scheduler patches from 4.4 kernel
    * Dynamic SchedTune Boost
    * Wireguard
    * Others and more to come...


    We recommend Kernel Aduitor/EX Kernel Manager for making kernel changes

    Kernel Downloads:
    RZ-OP3-OOS-1.3.0-181025-a6ba708e.zip
    RZ-OP3-OOS-1.2.0-180910-80c6d0c2.zip
    RZ-OP3-OOS-1.1.0-180724-0e8f55f2.zip
    RZ-OP3-OOS-1.0.0-180613-2f2d48c6.zip

    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 OOS kernel, please dirty flash OOS first
    * Flash RenderZenith!
    * 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/op3-oreo-kernel
    https://github.com/EAS-Project/AnyKernel2


    XDA:DevDB Information
    [Kernel] RenderZenith OP3/T [OOS-O-EAS-V1.3.0][25 Oct 2018], Kernel for the OnePlus 3

    Contributors
    RenderBroken, joshuous
    Kernel Special Features: Energy Aware Scheduling

    Version Information
    Status: Testing

    Created 2018-06-13
    Last Updated 2018-10-25
    61
    RenderZenith v1.1.0 released! (27 July 2018)

    RenderZenith v1.1.0 release for OOS!

    Please dirty flash OOS (stable/beta) before you flash this!

    Changes:
    * Upstreamed to Linux 3.18.116 via Android Linux Stable (thanks @nathanchance!)
    * Systemless build. You can now use ExKM and FKM to flash. You can now restore boot.img of OOS if you want to return back to stock OOS.
    * New Dynamic Stune Boost changes (see writeup below)
    * Enabled cpu-boost for Big cluster to reduce first frame janks
    * Disabled CONFIG_CC_OPTIMIZE_FOR_SIZE
    * Added option to disable MSM Touchboost (or more accurately the ability to disable CPU frequency boosting via BoostFramework)
    * Reduced wakelock duration for qcom_rx_wakelock (I won't block this though)
    * Added DTS Eagle and Audiowizard integration for IceWizard mod support. (Refer to https://xdaforums.com/apps/magisk/unity-icewizard-t3776470) Take note that I don't provide support for this mod.

    Systemless
    As this is a systemless build, there might be a possibility that WiFi might break if you use certain Magisk modules due to bind mount conflicts. If you face this issue, please figure out which module causes the breakage and let me know. Reports without some form of helpful info will be ignored.

    New Dynamic Stune Boost changes
    Like with many CAF-based OEM ROMs, OOS uses CAF's BoostFramework. BoostFramework detects various contexts, such as app launches, swipes, etc and triggers different boosting configurations. Besides CPU Frequency boosting (aka MSM Touchboost) it also triggers Scheduler Boost (called sched_boost in the kernel), which pushes tasks to the Big cluster for higher performance. It toggles sched_boost by writing to /proc/sys/kernel/sched_boost. sched_boost was a HMP/corectl feature that I removed in my EAS bringup because it interfered heavily with the EAS task scheduling system. However, I have brought it back (/proc/sys/kernel/sched_boost is back) but altered it to perform Schedtune boosting for top-app tasks instead. Whenever you scroll, fling or launch apps, BoostFramework will now cause schedtune boost value to dynamically change to the value that you configure in the new /dev/stune/top-app/schedtune.sched_boost file (Please read this carefully. Several testers reported it not working because they read the file name incorrectly and modified the wrong file :S). Take note that changing the other schedtune.sched_boost files in foreground/background/system-background/etc will do nothing because I did not configure them to be used.

    Why add this new sched_boost when we already have dynamic_stune_boost in cpu-boost kernel driver?
    The dynamic_stune_boost that is triggered by cpu-boost and does the same thing as /dev/stune/top-app/schedtune.sched_boost (and it does it faster too!). However the cpu-boost version has a limitation:
    - Fixed boost duration for cpu-boost. Comparatively, the sched_boost variant will automatically boost and unboost at the start and end of a fling/app launch, respectively. So you don't need to mess around with boost duration on the new sched_boost variant.

    The cpu-boost and sched_boost variant of Dynamic Stune Boost complement each other, and it is hence not a "choose one only" problem. The following should clarify:

    cpu-boost:
    + More responsive than BoostFramework
    + Triggers when tapping or dragging across the screen (e.g. typing)
    - Fixed boost duration. Needs to be configured to meet your needs.
    - Does not trigger for app launches and non-touch events

    BoostFramework:
    + Automatically manages boost duration
    + Triggers for app launches, swipes, flings, etc
    - Does not trigger on taps (e.g typing)
    - Slightly less responsive to boost compared to cpu-boost

    With this new schedtune boost, you can now imitate the Google Pixel's boosting completely (although it might be overkill for power consumption imo):
    • cpu-boost duration: 1400ms
    • cpu-boost frequencies: ~1.1GHz for both clusters
    • cpu-boost dynamic_stune_boost: 50
    • /dev/stune/top-app/schedtune.boost: 10
    • /dev/stune/top-app/schedtune.sched_boost: 50

    Download
    RZ-OP3-OOS-1.1.0-180724-0e8f55f2.zip
    52
    RenderZenith v1.2.0 released! (12 Sep 2018)

    RenderZenith v1.2.0 release for OOS!

    More delayed than I hope it would be, but here you go!

    Changes:
    • Upstreamed to Linux 3.18.122
    • More performance-oriented SchedTune boost changes
    • Added USB Fast Charging feature (charges at 900mA instead of 500mA on supported connections). Use at your own risk. Toggle via /sys/kernel/fast_charge/force_fast_charge

    Download
    RZ-OP3-OOS-1.2.0-180910-80c6d0c2.zip
    42
    For Devs that are interested in porting EAS:

    Hey guys! Just like we did for MSM8998 Devices, 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/msm-3.18
    41
    We decided to hold off on making our kernel system-less but that will be incoming soon. We just wanted more time to test it out before our first stable release. Also, we will be bringing in all the features RZ users have come to expect. We are thuroughly proud of this release. It embodies the learning and testing we have done on the OP5. With each iteration we step are game up higher and higher and I feel that it shows.