yashsingh1/xdaforums huggingface dataset:
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Right, i have been back to OOS 4.1.3 and left the awesome VertexOS, which means i am back to good ol' HMP again but for a very necessary reason.

You see, EAS has been massively updated in the recent weeks, so much that my earlier HMP vs EAS analysis has been invalidated, thanks to the changes done from the PowerHAL side that [MENTION=5438598]RenderBroken[/MENTION] and [MENTION=6745491]joshuous[/MENTION] have been working on, which introduces some things like interaction boosting parameters, and major EAS updates from the authors themselves that have been successfully merged (shoutout to those great great heads, cannot thank them enough!).

With that said, I think a revisit to such a useful analysis is desperately needed, and I am glad to inform you that I have started writing the HMP part of the comparative analysis revisit since I am on OOS 4.1.3 and running the stock kernel. That analysis should include some figures and thorough descriptions of the CPU behaviour, the performance and/or smoothness and efficiency per each scenario of my usage patterns, as well as some synthetic benchmarks, timed app launches and general conclusion concerning the battery life. There must be something to be made clear though. This analysis is based on my personal usage pattern, which includes small light-gaming sessions, medium browsing via Chrome, loads of YouTube streaming, music playback and minimal interaction with social media apps (I have no Instagram, no FaceBook, no Snapchat. Just Slack, Telegram, WhatsApp, Hangouts). While this may not be the case with all the users, it is safe to presume that at least the performance/smoothness part in these areas would gain attention from most users, if not all of them.

Last but not the least, I will be using the stock settings for HMP and the stock settings of RenderKernel on VertexOS official release for EAS, since it will take a while till we get a fully functional OOS-EAS build and even though we won't get a 100% EAS experience as you would with one of the Pixel phones, which gratefully has been achieved via VertexOS, thanks again to [MENTION=5438598]RenderBroken[/MENTION] and [MENTION=6745491]joshuous[/MENTION] :good:

So there you are, hope it turns out to be as useful as i intend to. I'll try to out as much work and precision in it as i can, even though life has been putting me under the weather lately. And with exams approaching, it does not get any better.
[OnePlus 3 & 3T Cross Device Development] vrda08:
What a kernel... I was very disapponted with eas kernels in begining.. and I tried this r5.. Amzing. No lags, no micro-lags, stutters, it is like a butter. Battery is very nice too.

Really impressed with this!!
[OnePlus 3 & 3T Cross Device Development] RenderBroken:
Can't wait to see what you come up with! We can add it to OP.

Glad you gave it another shot. I agree, I get even better performance and battery with my new EAS work. It is amazing to see how far it has come in such a short time period.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Status update: my analysis of HMP on OOS 4.1.3 is almost complete. Only the Bluetooth playback drain and YouTube drain to be analysed.
[OnePlus 3 & 3T Cross Device Development] patalao:
For what i've tested, EAS even with a bigger percentage on active drain can manage a very good balanced battery drain with a very smooth experience overall.

Only by tweaking HMP we can achieve similar results.

By having EAS with that performance and battery out of the box is a must for many people.

The problem is, it is still only for custom roms.

Other than that nothing wrong to mention about EAS.

At first it was like a baby trying to learn is first steps, now it's just more mature and could (will) improve more in the future.

Enviado do meu ONEPLUS A3003 através de Tapatalk
[OnePlus 3 & 3T Cross Device Development] JumboMan:
when I heard about EAS (Energy Awareness Scheduling ) some months back I thinked this is not going to useful for at least next 2 to 3 years. Thus is for future and its just introduced now.It will require lots of time to mature & useful.

But I am completely wrong because the work done on EAS by josh and Render is incredible that made EAS f**kingly awesome in such short time.

Added on that the custom power hal (Voxpopuli) by josh made it even better.

Thank to josh, Render, all testers and Google and Linux
[OnePlus 3 & 3T Cross Device Development] Konskl:
[MENTION=5060769]Mostafa Wael[/MENTION] [MENTION=5438598]RenderBroken[/MENTION] [MENTION=6745491]joshuous[/MENTION] First of all a BIG THANK YOU for the awesome Vertex rom. Either kernel side or rom side it's exemplary of smoothness and battery life. The only minor downside if it can be called that way is present in one isolated scenario at least according to my usage in which I'd like to ask your help. Even though schedutil is very friendly to battery life. I've noticed that frequencies like to jump really quite high (1248,1407 for the small cores and 1704 2046 for the big cluster) when I'm streaming via chrome or any other browser. That's important to note cause when I'm streaming content via an application or YouTube frequencies tend to stay at 307mhz most of the time which of course leads to longer screen of time sessions. In the beginning i though messing with the vox populi parameters but then I thought that while streaming I don't interact with the screen at all so messing with those parameters wouldn't change a thing. ( Correct me if I'm wrong in any way.) I tried to reproduce the same high frequencies in streaming via browsers with hmp kernels in OOS like blu spark or even stock kernel and that was not the case. Frequencies tended to rest low at 307mhz for all clusters. MY QUESTION IS: can we improve battery drain in that isolated scenario? My belief is that we can but I don't know what should be changed. Any input or advice would be GREATLY APPRECIATED. Again thank you for your awesome work. Peace
[OnePlus 3 & 3T Cross Device Development] joshuous:
You are right that Vox Populi only affects touch screen activity. You can try to reduce the drain by decreasing the value in /dev/stune/foreground/schedtune.boost to something negative. Let me know whether it makes an impact, and I'm glad you're enjoying it and giving great feedback
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
I normally don't stream videos for long periods of time via a browser, but if that issue of yours can be replicated by streaming a video on my Facebook feed via Chrome, I will be putting it under the scope. Also it is worth mentioning which app did you use to track the CPU behaviour? Last but not least, EAS has been just around for around a year or less, which means it is going to take time to be as refined as HMP. Think of it like training a dog and letting it know who are the people to pass the door and who should be vigorously bitten in their arse. And I am sure that as we speak the good chaps at Linaro or Google are working on some changes to further improve EAS ;)
[OnePlus 3 & 3T Cross Device Development] Konskl:
I'm sure that over time it will improve. Even as we speak I consider eas better in most scenarios be it performance or battery. On to the battery side. Ye try to stream any video in wny browser. Personally i use Chrome and you will find out that the cpu is jumping needlessly. Mind you, that the streaming is done in full screen also. In my view high frequencies shouldn't be needed at all when streaming content since it's considered quite light usage. I verified that with blu spark while streaming in OOS via chrome. Frequencies laid low which saved a lot of juice in my use case. If you get any clue about that let me know. ;)

EDIT: the app used to monitor was Cpu Float
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Right I have just done a test and I think I have a totally different experience here on HMP, more particularly on OOS 4.1.3 stock kernel with stock settings. Have a look at the screenshots attached below. Test was conducted by streaming a 1:30 video in my Facebook feed page in fullscreen by mobile data.
[OnePlus 3 & 3T Cross Device Development] JumboMan:
1.can anyone explain difference between top-app and foreground app

2. during scaling freq up/down, schedutil gov uses two parameters up_rate_limit_us & down_rate_limit_us.

are these values in microseconds(us) or milliseconds(ms)
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
1- top-app and foreground are cgroups by which tasks gets classified as. Each cgroup has its own schedtune settings by which you can inflate the perceived load or downscale it via schedtune.boost value (positive values will inflate the load while negative values will downscale it), as well as the ability to either disperse the load across the cores or keep it tight to the cores woken by that task via schedtune.prefer_idle (1 will disperse the load while 0 will keep it packed)

2- with a closer look to the tunables names, the answer can be obviously spotted, and that is microseconds

---------- Post added at 09:16 AM ---------- Previous post was at 09:11 AM ----------

Right I think I have spotted the reason. Looks like the CPU scheduler settings on stock OOS 4.1.3 kernel are probably a bit more different than what you can get from blu_spark HMP OOS kernel. In other words, the dev has tweaked it to keep on low frequencies for much longer time than stock kernel behaviour. Also were you using blu_active governor? Since he does some changes to the governor settings there as well, at least that is what I have witnessed last time I had blu_spark installed. A similar effect can be produced by installing an AKT balanced profile or a battery saving one. Please roll back to stock OOS kernel (disable any on-boot settings beforehand) and verify the CPU behaviour I have tracked and posted in my previous post (the one that I quoted you in).

Thanks!
[OnePlus 3 & 3T Cross Device Development] JumboMan:
[MENTION=5060769]Mostafa Wael[/MENTION]

I know schedutil and Interactive governor are completely different in how they work.

but still i some confusion.

I think up/down_rate_limit_us in schedutil works same as timer_rate in Interactive. am i right?

Timer rate in Interactive gov is usually set at 20k us while in schedutil rate limit Values are very low (in range of 500-3000us).

As per my limited knowledge lower the timer_rate/rate limit , higher will be frequency transitions.(up and down)

And it is always advised to lower frequencies transitions to get smoth jank free experience.

So my question is that setting very low values of rate limit in schedutil will result in less smooth experience ???

========

Question about schedtune.prefer_idle.

In terms of performance is it better to spread load across cores(1) or pack on same core which woken by that task(0)
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Schedutil determines the next frequency step to be used through the following algorithm

As you can see, it does rely solely on the data perceived by the CPU scheduler with no timers or anything like Interactive, which brings us to your question. What are these tunables? Well up_rate_limit_us is the minimum time in microseconds before moving to the next higher frequency. Same applies for down_rate_limit_us except that it gets in action only when the next calculated frequency is lower than the current frequency. In other words, lower time values for up_rate_limit_us makes the CPU frequency step up faster and lower time values for down_rate_limit_us will make the CPU frequency step down faster. So yes, the lower the time values the more frequent the frequency transition will be. What we have done is lowering the up_rate_limit_us to make the CPU move to the calculated frequency faster when the next frequency is higher than the current frequency, and increasing the down_rate_limit_us to make the CPU stay a bit longer on the current frequency, should the calculated next frequency be lower than current frequency. This setup guarantees you silky-smooth experience for sure. Something to note, this time period/rate_limit is measured from the last scheduler request.

---------- Post added at 10:03 AM ---------- Previous post was at 10:01 AM ----------

According to the provided documentation, it is better to spread the load across the cores performance-wise.

---------- Post added at 10:20 AM ---------- Previous post was at 10:03 AM ----------

EAS has always been around. In fact, it is not the first time to see it debutting in a consumer-targetted phone. OnePlus 2 had an early implementation of EAS, though it did not possess any different CPU governors like what we have now. The main target for that EAS implementation was to hotplug the cores of the flamethrower S810 in a 'rotary' manner in an attempt to dissipate the heat more effectively, though it was not as successful as the ambitious creatora hoped, partially because the OP2 had very aggressive policies from OnePlus's side.
[OnePlus 3 & 3T Cross Device Development] JumboMan:
[MENTION=5060769]Mostafa Wael[/MENTION],

On ZenithRender by josh and RenderBroken kernel values for schedtune.prefer_idle is set to 0 for top-app and 1 for background app.

We always want performance in current app (schedtune.prefer_idle value=1) while background app not utilizing lot of cpu (schedtune.prefer_idle value=0)

can you explain why these kernel settings value opposite
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
I assume that is an accidental mistake.

However, in the documentation provided by Google, setting schedtune.prefer_idle to 0 for Foreground and slightly boosting it via schedtune.boost will result in better battery life with no noticeable performance regressions. Nevertheless I am sure what you have found is nothing but a simple mistake in some scripts or something like that.
[OnePlus 3 & 3T Cross Device Development] JumboMan:
Lots of tanks brother for answering my questions.

Now i am going to set values schedtune.prefer_idle as per your recommendation.

I will report back my experience after thorough testing.
[OnePlus 3 & 3T Cross Device Development] Konskl:
Ye i was using blu_active governor. Maybe that's the reason. My thinking is that if we manage to reduce the jumping in frequencies during streaming scenarios we'll get way better battery life without compromising performance at all. Not sure though what to tweak to get that result. Any suggestion would be welcome.

---------- Post added at 04:04 PM ---------- Previous post was at 03:48 PM ----------

To my understanding setting schedtune.prefer_idle to 1is like enabling the toggle of making the apps to prefer idle. Wouldn't it be better if we set schedtune.prefer_idle to 1 for background apps and 0 for foreground and top-app?
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Per-app/per-scenario engine or a custom governor. You can try with PELT variant of RenderKernel and see how it goes
[OnePlus 3 & 3T Cross Device Development] Konskl:
Nothing changed by putting negative values. Still frequency jumping is there. The weird thing is that that reaction to streaming happens only during streaming via browser. While streaming From YouTube app be it 60fps 1080p content frequencies lay low. Also what I'd like to ask you is the reason why you keep schedtune.prefer_idle to 0 for background apps and schedtune.prefer_idle to 1 for foreground apps. Wouldn't it be idling better if you kept prefer_idle to 1 for background apps. In other words isn't the 0 the same as disabling the function? Ty in advance

EDIT: [MENTION=5438598]RenderBroken[/MENTION] clarified the issue. So schedtune.prefer_idle refer to the tasks whether or not to prefer to use idle cores not for the phone to prefer or not to go idle. Anyway that's quite an informative thread we have here. Big thanks. And yes indeed even according to my own usage scenario EAS provides a way smoother UI.. let's hope that your OOS EAS kernel will make the OOS as smooth as vertexOS ;)
[OnePlus 3 & 3T Cross Device Development] joshuous:
Prefer idle doesn't mean that we want the CPU to be idle. The schedtune.prefer_idle means that we prefer to place tasks on idle cores, rather than already busy cores. This method results in lower latencies for top-app and foreground activities.
[OnePlus 3 & 3T Cross Device Development] JumboMan:
[MENTION=5438598]RenderBroken[/MENTION].

Thanks for easy to understand explanation
[OnePlus 3 & 3T Cross Device Development] Konskl:
Ye i was a little late but i got it :P one last question regarding the kernel. Is dynamic fsync completely different from the fsync? Because in ex kernel manager i get two toggles. One for fsync and the other for dynamic fsync both enabled. In the OP of Vertex you say that dynamic fsync speeds up random writes but from the ex kernel thread i remember that disabling (plain fsync) increases i/o speeds. So in terms of performance isn't it better to disable fsync and leave dynamic fsync enabled or by disabling fsync i mess up with the dynamic fsync as well?
[OnePlus 3 & 3T Cross Device Development] joshuous:
Unless you're on [MENTION=5438598]RenderBroken[/MENTION]'s kernel, you should be messaging this on my thread instead. Disabling Fsync increases random write speeds. Fsync provides a means to check that data has been successfully written, but this introduces a bit of latency for each check. When you do a lot of random writes, the latencies accumulate greatly. Sequential writes aren't affected much as data is being written in a continuous block.

Dynamic Fsync is a mechanism to disable Fsync when your screen is on and enable Fsync when screen is off, so that we take advantage of improved random write speeds only when we need it.

If you want all out performance at the risk of data loss on writes (if your phone crashes somehow), disable Fsync entirely.

Otherwise, leave Fsync on and enable Dynamic Fsync for a safer middle ground. I recommend this.

If you want to play it totally safe, enable Fsync and disable Dynamic Fsync
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Would like to note something. With EAS's smarter tasks placement, this guarantees you a flawless 60 fps experience even if you have some background tasks being processed since they will get completed in parallel with the Foreground and top-app tasks, thanks to each task taking a well quantified sliver of the available firepower and not just blindly being processed by all the cores or being over-weighed and receiving much more power than needed. Think of it as follows. EAS is like a good flawless man with good eyesight while HMP is like a poor-sighted man that limps on his guiding stick.
[OnePlus 3 & 3T Cross Device Development] lostdream:
support dash charging? and which partition support f2fs? does system and chace support? thx
[OnePlus 3 & 3T Cross Device Development] frickinjerms:
Yes and only f2fs only on /data I believe but I don't think bug support is offered if you're on f2fs as it's still essentially beta
[OnePlus 3 & 3T Cross Device Development] nevermorenorless:
This is a pretty noob question but will rq affinity effect EAS in any way?
[OnePlus 3 & 3T Cross Device Development] ndarkside93:
You'd most likely want it set to 0 so EAS can pick any could for team placement as needed
[OnePlus 3 & 3T Cross Device Development] habylab:
Any chance of an update to the OOS kernel? It's been a while now, but EAS worked well!
[OnePlus 3 & 3T Cross Device Development] Skinpipe:
Hes doing it man, chill

Or stop using Oos and use vertex os or Phoenix os
[OnePlus 3 & 3T Cross Device Development] habylab:
Just a question :)
[OnePlus 3 & 3T Cross Device Development] Balino:
I finally made the jump to a custom ROM, aex for the moment, and I'm really pleased by your kernel. Performance is superb and battery life is quite good for the moment. It's the first run so I can't really tell how it differes from oos stock ROM and kernel. I had a great battery life on oos as well, I hope it will get better on the next run. I attached some screenshots to show how it's going at the moment. Thank you very much for the update I'm really looking forward to the oos version, I'm lost on aosp ROMs, I got really used to oos.
[OnePlus 3 & 3T Cross Device Development] kkcckkcc:
will you support los-m

for me some apps still have bugs on n

i have used VertexOS for three days

the kernel is stable and great:good:
[OnePlus 3 & 3T Cross Device Development] nasbdh9:
The phone will not be able to dial / answer after a long period of standby？
[OnePlus 3 & 3T Cross Device Development] ndarkside93:
I won't waste his time or yours. Unfortunately he won't be backporting to marshmallow
[OnePlus 3 & 3T Cross Device Development] masri1987:
No oos 4.1.x update? Been checking every day
[OnePlus 3 & 3T Cross Device Development] lutyjj:
Soon™.

Sooner than AOSPA's Soon™ :D
[OnePlus 3 & 3T Cross Device Development] Puddi_Puddin:
He is busy.. Such things just need alot of time.
[OnePlus 3 & 3T Cross Device Development] Wani Aamir:
Can i flash this kernel over that?
[OnePlus 3 & 3T Cross Device Development] ahepas:
Yes you can... But the differences are not so many I believe... It's basically the same kernel... Try it!

Στάλθηκε από το ONEPLUS A3003 μου χρησιμοποιώντας Tapatalk
[OnePlus 3 & 3T Cross Device Development] afrob:
Download link in #1 dosent work for me.
[OnePlus 3 & 3T Cross Device Development] Bob823:
Phone was unresponsive today with EAS. Had to reboot manually. [MENTION=5438598]RenderBroken[/MENTION]
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
It is all down to the top-apps thing. Got that working, it will be done!

[MENTION=5438598]RenderBroken[/MENTION] your latest non-EAS build is pretty much stable for me here.

About the EAS kernel, which EAS implementation are we using? As far as I know there are multiple ones like the one in the Pixel, there is one from Linaro and even Qualcomm has its own EAS. So which one are we having under the bonnet here?
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
This is EAS with schedtune.boost=4

Brightness is 40% tho, and it was WhatsApp, Telegram, XDA Labs, Facebook and Slack all the time.
[OnePlus 3 & 3T Cross Device Development] MBurns2:
Which app do you use for this test? Thanks
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
CoolTool
[OnePlus 3 & 3T Cross Device Development] MBurns2:
Did you only active batteryma in label? Ty
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Enable what you want, but yes that is the one to enable.
[OnePlus 3 & 3T Cross Device Development] MBurns2:
Sorry for the ot, last message i promise: batteryma refresh every minute right? It is not possibile to decrease that time?
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
I don't think we can do so sadly...
[OnePlus 3 & 3T Cross Device Development] RenderBroken:
I have been wanting to try out cf.lumen. Work pretty well? I normally keep my screen bright at about 80%. No sense in having a smartphone for work if it is going to lag and have a hard time reading it.

I believe this is what the Pixel is using. and really,. the major premise of EAS is all the same for all versions of it and that is to let the scheduler control freq/voltage on an as needed bases instead of a reactionary bases in CPUFREQ. Currently, our HMP setup uses a bunch of scheduler hints.

I love CoolTool and use it all the time as well for testing. You can even have it track custom sysfs files.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Yes man, I used to track the GPU freq, cpu temps and all. Awesome!
[OnePlus 3 & 3T Cross Device Development] tathagatab:
CF.Lumen is very customizable. You can choose the brightness levels at which it switches among the 3 modes. You can choose the exact hue you want for each mode, and the defaults are pretty useful too. You can set sunset and sleep times manually or by GPS. The optical driver is high-quality, the colours look beautiful and the transitions are smooth. IMHO, it's worth paying for the pro version.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
[MENTION=5438598]RenderBroken[/MENTION] you latest nonEAS kernel is staggering!!!