• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8]

Status
Not open for further replies.
Search This thread

RenderBroken

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

for OOS-N, and LOS-N​

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
*/

I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want 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.

Wanna be notified of an Update? Here is my PushBullet Channel!!
https://www.pushbullet.com/channel?tag=renderkernel


Current Features
General List:

* EAS Only
* Built with LINARO 6.x
* Updated with CAF LA.UM.5.5
* IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
* Flar Sound Control
* Wake Gestures - DT2W, S2W, and S2S
* Complete Color Calibration Thanks to @savoca
* F2FS Support
* Adrenoboost
* USB Fast Charging


I recommend Kernel Aduitor for making kernel changes

Kernel Downloads:
LOS-(EAS/HMP) Downloads
OOS-(EAS/HMP) Downloads

Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything!
* At least backup BOOT via TWRP
* Flash Zip
* Reboot


THANKS!!!!
First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:

Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!

Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today


Special Thanks!

Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1

Source Links:
https://github.com/RenderBroken/OP3-kernel
https://github.com/RenderBroken/OP3-LOS-kernel
https://github.com/RenderBroken/RenderKernel-AnyKernel2



XDA:DevDB Information
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3

Contributors
RenderBroken, Mostafa Wael, joshuous
ROM OS Version: 7.x Nougat

Version Information
Status: Testing

Created 2016-11-23
Last Updated 2017-12-15
 
Last edited:

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,084
33
/home/renderbroken/android
Note:

Great write-up from @Mostafa Wael

HMP vs EAS - OxygenOS 4.1.3 stable
Right here we go!
First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here

MMX Hill Dash
HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!

True Skate
HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.

Browsing via Chrome
HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.

YouTube streaming
HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.

Overall battery life
HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.

let's get to the numbers...

App launches
[HMP]
PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU

CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size

[EAS]
PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec

Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU

CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
.

Synthetic Benchmarks
[HMP]
AnTuTu: 148,471
Geekbench 4.1.0: 1733 + 4191
Vellamo - Multicore: 3215
Vellamo - Metal: 3541
Vellamo - Chrome: 4825
[EAS]
AnTuTu: 143840
Geekbench 4.1.0: 1740 + 3290
Vellamo - Multicore: 2511
Vellamo - Metal: 3569
Vellamo - Chrome: 4350
This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....
 
Last edited:

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,084
33
/home/renderbroken/android
Reserved

An amazing write up by a talented dev @joshuous:

PELT and WALT

Time for me to flex the analogy muscles.

Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".

One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.

On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.

In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.

So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.

Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.

Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it
 
Last edited:

RenderBroken

Recognized Developer
Sep 14, 2013
4,297
20,084
33
/home/renderbroken/android
Me too!! I love render since lg g2 times.. Thanks Render for coming here :)

Thanks! Glad to be here!

omg another kernel. Im so exited :D !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!

I appreciate the kind words!

Everyone, please remember to provide logs in case of a reboot. I dont like to release such builds but it will happen from time to time. Especially when porting new features such as EAS.

You can get a log from

/sys/fs/pstore/console-ramoops
 

Puddi_Puddin

Senior Member
May 10, 2015
1,521
493
Overijssel / Oldenzaal
Great! EAS is really where I was hyped for! Thx for your amazing work!.

I'm going to run it 24 hours and see if there are any reboots, if there won't be ill let you know. I noted that the Cpu frequency stays quite high when there is barely any load? Is this normal?

Edit: issue with standby, couldn't get my phone on when I didn't use it for like 3-4 minutes. Had to reboot, but couldn't reproduce the problem
Issues I encountered:
1. Had an instant where my phone's screen was off for 2 minutes, i couldnt get the screen back on so i had to reboot. Yet i failed to reproduce the issue. (Logs didnt show anything)
2. CPU frequency seems to be really overkilling a task. It doesnt like to stick to 300Mhz either.
Other then that it works smooth and flawless! Even Snapchat is now using all 4 cores instead of only 2 little ones on HMP.
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

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

    for OOS-N, and LOS-N​

    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
    */

    I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want 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.

    Wanna be notified of an Update? Here is my PushBullet Channel!!
    https://www.pushbullet.com/channel?tag=renderkernel


    Current Features
    General List:

    * EAS Only
    * Built with LINARO 6.x
    * Updated with CAF LA.UM.5.5
    * IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
    * Flar Sound Control
    * Wake Gestures - DT2W, S2W, and S2S
    * Complete Color Calibration Thanks to @savoca
    * F2FS Support
    * Adrenoboost
    * USB Fast Charging


    I recommend Kernel Aduitor for making kernel changes

    Kernel Downloads:
    LOS-(EAS/HMP) Downloads
    OOS-(EAS/HMP) Downloads

    Instructions:
    * Boot into Recovery
    * (Recommended) Make a complete backup of everything!
    * At least backup BOOT via TWRP
    * Flash Zip
    * Reboot


    THANKS!!!!
    First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:

    Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!

    Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today


    Special Thanks!

    Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1

    Source Links:
    https://github.com/RenderBroken/OP3-kernel
    https://github.com/RenderBroken/OP3-LOS-kernel
    https://github.com/RenderBroken/RenderKernel-AnyKernel2



    XDA:DevDB Information
    [UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3

    Contributors
    RenderBroken, Mostafa Wael, joshuous
    ROM OS Version: 7.x Nougat

    Version Information
    Status: Testing

    Created 2016-11-23
    Last Updated 2017-12-15
    73
    @RenderBroken
    Missing render kernel in my op3t 4.5.1 .

    He's been super busy getting latest blobs for many devices and put more together. Let's remain patient.

    I have finally finished my other endeavors and will be focusing on the op3(t). I am excited to show you guys what @joshuous and I have in store for you all. We have been planning our o-eas work for sometime now and I feel confident that we will surpass what we did on N. I appreciate the patience from everyone while allowing us to pursue our projects in peace. It just goes to show that we have the best community out there.



    Soon....
    ;)
    70
    Note:

    Great write-up from @Mostafa Wael

    HMP vs EAS - OxygenOS 4.1.3 stable
    Right here we go!
    First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here

    MMX Hill Dash
    HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
    EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!

    True Skate
    HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
    EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.

    Browsing via Chrome
    HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
    EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.

    YouTube streaming
    HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
    EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.

    Overall battery life
    HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
    EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.

    let's get to the numbers...

    App launches
    [HMP]
    PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
    Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
    YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
    Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
    WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
    Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
    Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
    Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
    Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
    MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
    Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
    True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
    XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
    Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU

    CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size

    [EAS]
    PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
    Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
    YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
    Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
    WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
    Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
    Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
    Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
    Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
    MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
    Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
    True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
    XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec

    Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU

    CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
    .

    Synthetic Benchmarks
    [HMP]
    AnTuTu: 148,471
    Geekbench 4.1.0: 1733 + 4191
    Vellamo - Multicore: 3215
    Vellamo - Metal: 3541
    Vellamo - Chrome: 4825
    [EAS]
    AnTuTu: 143840
    Geekbench 4.1.0: 1740 + 3290
    Vellamo - Multicore: 2511
    Vellamo - Metal: 3569
    Vellamo - Chrome: 4350
    This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
    Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
    Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....
    59
    RK-LOS-N-EAS-R4 is HERE!!!

    Things to note:
    This build has been a huge project. Not only was I doing this work for the OP3(T), I was doing this work to lay down the groundwork for other Devs to port and use to bring EAS to their devices. I have collaborated all over XDA. If we can get EAS taking off faster, then maybe more OEMs can see the benefits of it. I have rebased, my rebase, of a rebased rebase and finally landed on what we are using today. I have thoroughly testing with the LISA Toolkit from ARM. Then I added all the normal Render Kernel features that DID NOT create performance regressions. Now, we have R4. I have build a PELT and WALT variant. Right now I prefer and recommend WALT. This is QCOMs solution to Load Tracking and is very interactive. PELT is in mainline linux and uses CFS (Completely Fair Scheduler) as its base and uses Load Decay. This one ramps up and down slower. So the fast load changes where WALT may cause SCHEDUTIL to lower frequency, PELT may continue to carry the load through this period. In theory that is. For Me WALT seems to just be better all around but the future goals of EAS is to have PELT become more competitive with WALT.

    You have a questions? Ask it! There is only one way to learn and that is by digging in. Please let me know how it works for you.

    Download

    Changelog
    53
    Hey guys!

    Sorry for being absent of late. Just been busy as hell again. So much so that even in my free time, I just had to take it easy. I did get the OP5 as well and love it! The jelly effect is such a minor annoyance but it is still an annoyance. Though it's so minor that the OP5 is still the greatest bang for the buck. Main thing for me was to bring EAS to the SD835. So far I am blown away with the OP5 as the performance gain over the OP3 is dramatic IMO. The battery gain as well is dramatic when compared to my OP3. I will be continuing development for the OP3 as well for those curious. I am hoping to bring both phones inline enough with each other so that I can just make the same changes to all kernel builds I am doing. I have alot more EAS changes incoming as well. I just wanted to give an update for those interested. Thanks guys for all the support here and in my Slack Group.

    Kind Regards,
    Render