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

Search This thread
By:
Advanced…
joshuous

joshuous

Recognized Developer
Jun 7, 2015
1,155
5,598
Mostafa Wael said:
Couple of weeks ago, Joshuous wrote a new feature, namely Dynamic SchedTune Boosting, that’s been incorporated in recent RenderZenith kernel builds, which essentially alters the value of schedtune.boost for the top-app cgroup dynamically on touch events, to conserve battery. But still, the solution was not that flawless, since it didn’t migrate the task to the big cores when essential as Joshuous previously explained. A quick workaround was to increase the value of /dev/stune/top-app/schedtune.boost to 1 (at least) to allow the utilization of the big cores when required. Many of you may be wondering why that was necessary. Well, hopefully I can break it down a bit for you.

Given the task that needs processing, the find_best_target() function – that is responsible for placing the tasks on the suitable cluster – iterates firstly on the big cluster when the SchedTune boost value is greater than 0, whereas the little cluster will be iterated firstly, should the value of SchedTune boost be equal to or less than 0, to save power. What SchedTune boost does is inflating the task and CPU utilisation fed to the scheduler, and therefore impacting the OPP selection and allowing the task to be placed on the big core(s) if needed. What the older version of Dynamic SchedTune Boosting did was rather inflating the value of utilisation going into Schedutil governor, that is then used to determine the frequency step to be selected for the task via a linear formula, which consequently increases the calculated frequency. But since the value of utilisation going into the scheduler is not inflated, the placement of the task on the corresponding core(s) won’t be impacted and therefore, the task won’t be moved to a big core instead. In essence, the older version would only increase the frequency and not impact the tasks placement on the cores. This caused a drastic performance difference compared to what you get when setting the SchedTune Boost value statically.

With the new v2 version, Dynamic SchedTune Boosting will directly change the value of /dev/stune/top-app/schedtune.boost directly, addressing the issue of only inflating the utilisation data going to the schedutil governor, and therefore the tasks should be able to move to the big cluster when demanded as well as increasing the CPU frequency. This will allow us to safely leave the value of /dev/stune/top-app/schedtune.boost at 0 and save some power for low-medium workload scenarios, since the tasks will be moved to the big cluster on touch with no issues.

-TDK
Click to expand...
Click to collapse

Very well explained Mostafa :)
And thanks for saving me the time

To add on, don't be alarmed to see /dev/stune/top-app/schedtune.boost having the same value as dynamic_stune_boost when you want to edit it because your touches trigger the boosting. Just write the value you want into the file and save. It will automatically update the default stune boost value when the boosting stops. To confirm it, you can connect your phone to computer and do

adb shell cat /dev/stune/top-app/schedtune.boost

to confirm that it has changed. You gotta wait a second or so before you issue that command.

I would recommend keeping the /dev/stune/top-app/schedtune.boost at 1 or higher if you want lower latency when Dynamic Stune Boost kicks in. Reason being that default stune boost of 1 somewhat ensures that most of the top-app tasks are already on Big cluster so that we don't have to suddenly migrate too many tasks from Little to Big when Dynamic Stune Boost kicks in.

If you don't type much, and watch videos or listen to music mostly, then setting default stune boost to zero may save you more battery
 
Last edited:
  • Like
Reactions: yChoon, maddes1402, Sukhi and 6 others
Mostafa Wael

Mostafa Wael

Inactive Recognized Contributor
Jan 11, 2013
6,107
5,568
26
Gotham
Initial impressions: everything seems to be kicked up by a notch. Noticeably less dropped frames now and I think app loading is slightly faster as well. Battery drain rate is now lower too. For the same usage pattern, active drain rate is now less than what I used to get before by 2%/hr. Still haven't gotten to observe any noticeable changes in idle drain rate. You should be really enjoying this release :good:
 
ipredatorv

ipredatorv

Senior Member
Jul 4, 2017
271
84
RenderBroken said:
Thanks. Yea its something we are still working on, it doesnt always happen for me and there is not any real leads but we have a few things that we have looked into, a couple more to go though.
Click to expand...
Click to collapse
Youtube stuttering also happens for me @1080P60 and 720p60 since I believe version 1.5.

Could I provide a log or be useful in another way to help you guys?

Other than that YouTube issue, I'm thoroughly enjoying this Kernel ;) thanks a lot for your work, time and effort put into it.
 
  • Like
Reactions: MSephiroth, Spencervb256 and RenderBroken
joshuous

joshuous

Recognized Developer
Jun 7, 2015
1,155
5,598
ipredatorv said:
Youtube stuttering also happens for me @1080P60 and 720p60 since I believe version 1.5.

Could I provide a log or be useful in another way to help you guys?

Other than that YouTube issue, I'm thoroughly enjoying this Kernel ;) thanks a lot for your work, time and effort put into it.
Click to expand...
Click to collapse

No need, if it's easily reproducible @RenderBroken and I know how to get it ourselves :)
 
  • Like
Reactions: MrPepperino, ipredatorv, PeteT and 3 others
RogerF81

RogerF81

Senior Member
Oct 14, 2015
1,985
1,415
Stuttgart
Xiaomi Poco F3
Google Pixel 8 Pro
So far, first battery circle respectively first day on 1.7.0, and my conclusion: Great! Performance is even better than before, battery is about the same, perhaps slightly better. Again, everything seems super-stable, just awesome! Thanks for this! :)
 
xxBrun0xx

xxBrun0xx

Senior Member
Jan 1, 2012
2,304
713
CT
Samsung Galaxy Z Fold2
Was an avid Franco kernel user for a while, but eventually switched back to stock. This performs noticeably better than stock. Battery seems to be pretty close to stock, which is fantastic imo. Everything seems MUCH more stable than some of the early EAS builds. Awesome job, definitely my new daily driver.

Update: had Bluetooth randomly disconnect while driving (I Bluetooth tether to my head unit). Also get freezes on camera portrait mode and camera crashes.
 
Last edited:
  • Like
Reactions: joshuous and RenderBroken
C

char101

Senior Member
Jan 13, 2011
112
78
With 1.7.0 I have a lof of these lines in logcat.

Code: 
10-25 11:20:17.266   680  4496 E ANDR-PERF-OPTSHANDLER: Failed to read /proc/sys/kernel/sched_boost
10-25 11:20:17.267   680  4496 E ANDR-PERF-RESOURCEQS: Failed to apply optimization [3, 0]
10-25 11:20:18.570   680  4496 E ANDR-PERF-OPTSHANDLER: Failed to read /proc/sys/kernel/sched_boost
10-25 11:20:18.570   680  4496 E ANDR-PERF-RESOURCEQS: Failed to apply optimization [3, 0]

Code: 
OnePlus5:/ # cat /proc/sys/kernel/sched_boost
sh: cat: /proc/sys/kernel/sched_boost: No such file or directory
 
S

stoyanovvitalii

Member
Mar 20, 2013
39
14
Saint-Petersburg
I have a lot "failed to apply optimisation"
 

Attachments

  • Screenshot_20171025-103825.jpg
    Screenshot_20171025-103825.jpg
    217.1 KB · Views: 907
K

Konskl

Senior Member
Feb 13, 2015
579
162
Mostafa Wael said:
Initial impressions: everything seems to be kicked up by a notch. Noticeably less dropped frames now and I think app loading is slightly faster as well. Battery drain rate is now lower too. For the same usage pattern, active drain rate is now less than what I used to get before by 2%/hr. Still haven't gotten to observe any noticeable changes in idle drain rate. You should be really enjoying this release :good:
Click to expand...
Click to collapse

What top-app schedtune boost and dynamic schedtune boost values do you suggest for lag/stutter free experience? I really value your opinion when it comes to performance since you had made in the OP3 days the shotgun profile. I'm looking primarily for performance and smoothness all around.
 
Mostafa Wael

Mostafa Wael

Inactive Recognized Contributor
Jan 11, 2013
6,107
5,568
26
Gotham
Konskl said:
What top-app schedtune boost and dynamic schedtune boost values do you suggest for lag/stutter free experience? I really value your opinion when it comes to performance since you had made in the OP3 days the shotgun profile. I'm looking primarily for performance and smoothness all around.
Click to expand...
Click to collapse
Well I am using all stock settings, just the top-app boost reduced to 0 and it is still very smooth - and the battery savings are pretty much considerable. If you aim at very lag free experience, bump up dynamic stune boost to something like 25 and keep top-app boost set to 1 (default value in RenderZenith kernel). I would also increase the duration of CPU boost to 3000-5000 ms. Other than that, there is not that much to fiddle with. :good:

---------- Post added at 09:15 AM ---------- Previous post was at 09:08 AM ----------
stoyanovvitalii said:
I have a lot "failed to apply optimisation"
Click to expand...
Click to collapse
That relates to the perfd binary in OOS. Simply said, it is a binary that dynamically alters some settings to provide better experience and basically boosting the CPU in tough situations like when you open the app or something. However, that binary is tailored to dynamically alter some HMP-specific settings (CPU governor and scheduler settings most likely). And since EAS settings are completely different than those of HMP (governor settings for instance is just the rate_limit tunables, compared to Interactive's loads of governor settings like target_load and whatnot. Same applies to the CPU scheduler - the settings are completely different), the perfd binary fails to dynamically change those HMP-specific value because the settings are simply not found (in /proc/sys/kernel) to change their values, hence the errors. A solution for that would be stopping perfd via EXKM or via Terminal Emulator app (by typing su, followed by "stop perfd" - without the quotes). But I don't believe it will make that much of a significant difference to your experience. You can give it a try and tell us if you notice any difference in how smooth the UI is with perfd enabled and disabled.

---------- Post added at 09:16 AM ---------- Previous post was at 09:15 AM ----------
char101 said:
With 1.7.0 I have a lof of these lines in logcat.
Click to expand...
Click to collapse
Check my previous reply ^^

---------- Post added at 09:19 AM ---------- Previous post was at 09:16 AM ----------
ipredatorv said:
Youtube stuttering also happens for me @1080P60 and 720p60 since I believe version 1.5.

Could I provide a log or be useful in another way to help you guys?

Other than that YouTube issue, I'm thoroughly enjoying this Kernel ;) thanks a lot for your work, time and effort put into it.
Click to expand...
Click to collapse
Well I have provided the required log file (Systrace) earlier here on the thread, and I am sure a solution will be found soon. I am already digging in deep and trying to find the culprit with the help of others as well.
 
  • Like
Reactions: char101, maddes1402, joshuous and 2 others
R

Rhathaway

Member
Dec 1, 2015
24
2
Anyone else losing Wi-Fi? Installed straight after a dirty flash of stock OOS and doesn't work. I'm unrooted if that's an issue, but haven't seen it on previous versions (using custom roms)
 
ipredatorv

ipredatorv

Senior Member
Jul 4, 2017
271
84
Rhathaway said:
Anyone else losing Wi-Fi? Installed straight after a dirty flash of stock OOS and doesn't work. I'm unrooted if that's an issue, but haven't seen it on previous versions (using custom roms)
Click to expand...
Click to collapse
Root with Magisk, should fix the WiFi. This has been reported multiple times in other threads, and people said missing rooting is the "root" of this problem.
 
joshuous

joshuous

Recognized Developer
Jun 7, 2015
1,155
5,598
Just in case anyone is interested, the Pixel devices (v1 and 2) use a 'dynamic' stune boost of 50 and a regular /dev/stune/top-app/schedtune.boost of 10, which is one of the major reasons why they are so smooth. I'm testing atm and gonna observe battery drain
 
Last edited:
  • Like
Reactions: maddes1402, Spencervb256, velimirchek and 1 other person
S

Stupifier

Senior Member
Jun 8, 2010
1,914
680
joshuous said:
Just in case anyone is interested, the Pixel devices (v1 and 2) use a 'dynamic' stune boost of 50 and a regular /dev/stune/top-app/schedtune.boost of 10, which is one of the major reasons why they are so smooth. I'm testing atm and gonna observe battery drain
Click to expand...
Click to collapse
Jeez.....overkill much. I mean, I guess if battery is unaffected by such high values, I'd do it
 
P

prajnay

Senior Member
Sep 17, 2016
349
97
Is it normal that the big cluster is running 2.4 GHz 96% of the time
 

Attachments

  • Screenshot_20171025-184257.jpg
    Screenshot_20171025-184257.jpg
    108.2 KB · Views: 420
Last edited:
You must log in or register to reply here.

Similar threads

xXx
[ROM] xXx NoLimits [OOS][OP5/5T] ☆ Speed/RAM optimized ☆ [Stable & OB Roms]
Replies
19K
Views
2M
H
hobi177
nathanchance
  • Locked
[EOL] [OP5] [OOS/CUSTOM 8.1.0] [4.4.140] [CLANG 7.0] Flash Kernel v4.29
Replies
2K
Views
199K
nathanchance
nathanchance
franciscofranco
[KERNEL][OP5] FrancoKernel ?- r49 - 27th Aug · Pie & custom roms
Replies
2K
Views
267K
A
AlexMirrors
flar2
[KERNEL] ElementalX-OP5
Replies
1K
Views
188K
FeintDoxx
FeintDoxx
A
[KERNEL] [KALI-NETHUNTER] Burgerhunter/Dumplinghunter [OOS]
Replies
1K
Views
198K
seppzer0
seppzer0

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 89
    RenderBroken
    RenderBroken
    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
    View
    74
    joshuous
    joshuous
    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"
    View
    67
    joshuous
    joshuous
    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
    View
    64
    RenderBroken
    RenderBroken
    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.
    View
    46
    RenderBroken
    RenderBroken
    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
    View

New posts