[OnePlus 2 Android Development] Pierre2324:
NoGravityKernel EAS​

Kernel Features EAS

Same features as Non-EAS kernel + the following

Energy Model fitting OnePlus 2 and NGK's overclock

Schedtune + Dynamic Schedtune Boosting

Sched and Schedutil Governors

Optional SQRT frequency selection algorithm

PELT & WALT Load Trackers

Prefer Idle tunable

1000Hz Time Interrupt frequency to fit Pixel Phones instead of previous 300Hz

3.18 Kernel Preempt

3.18 CpuFreq upstreams

Using cpu_input_boost driver for event based boosting (replacing cpu_boost)

Many more upstreams and backports to our 3.10.108 kernel

Download Links

EAS Q-PIE-OREO AOSP Based Roms

EAS Q-PIE-OREO LineageOS Based Roms

As I put a lot of time and effort into this project, I now accept donations feel free to help me a little :cool:

Donate

Changelog

Public Changelog of private startup builds

post#2 for public released build changelogs.

Source: [url]https://github.com/Pierre2324/EAS_NGK_android_kernel_oneplus_msm8994[/URL]

More info on EAS and the specific implementation for OnePlus 2

EAS | Energy Aware Scheduling

Notice : I will not tell you everything about it.. I'll just do my best to summarise it up and, most importantly, say what's the implementation of it in my kernel compared to newer phones... I don't know everything and may do some mistakes (english mistakes included ;) ) if I do, let me know but still should be on track. I will highlight important words in bold. Also for better kernel tuning, please use my app as its made for our specific implementation of EAS.

Intro: Well Google mostly wanted a better/smarter algorithm to ramp up frequencies than the current cpu-boost driver.. So they started to make the kernel smarter on their 3.18+ kernel seen on Pixel Phones. They wanted to port EAS to their previous phones (Nexus 5x and 6p) having 3.10 kernel like the OnePlus 2 but they didn't.. They started porting it with a pretty basic implementation with a bad energy model, a pretty old version of the battery oriented Per Entity Load Tracking, a pretty basic Schedtune support too and the old Sched governor instead of the newer SchedUtil governor used on current/newer phones. That basic implementation was actually the first releases here on XDA before 3.0 update.

Energy model: At the base of a good EAS implementation there's an Energy Model containing compute capacities and energy cost tuples for each Cluster (big.Little). That way, its possible to estimate the cost of task placement on CPU. Hmm okay that was a big sentence here.. Well to summarise it up, some tasks need more compute capacity to run nicely (smoothly,fast,etc) so need more power which will cost more to run and depending on the task it may need to run on the Big cluster. I say that the kernel is smarter that way, since it will try to set tasks on cores that needs less power to run while still being fast enough for the task. It will also decide to use a shallow core instead of waking another from deeper since the energy model also specify wakeup costs.

What I did for the Energy Model until now: Since the Angler energy model that was used in first releases was pretty bad, I converted it to a frequency / cost model instead of capacity / cost which is now much easier to manipulate instead of speedbins. I then recalculated costs for each frequencies with some graphs including voltages for every frequencies to determine cost for both Cluster. For overclocked frequencies, I had to extrapolate/interpolate trend lines I had in those graphs. That way, we now have an Energy Model that corresponds better to our OnePlus 2 device. Some changes might need to be done later on, but it seems okay for now.

Sched Governor: EAS's Sched or newer Schedutil both use SMP -> Symmetrical multiprocessing instead of previous HMP -> heterogeneous multi-processor found for interactive, ondemand, etc... HMP and SMP both have in mind that multiple CPUs are running, but on SMP no CPU is selected as the Master CPU.. both CPU cooperate as friends.. Well we all know there is a big difference between our little and big CPU and this is why the governor is not alone in EAS..On the other side, HMP knew exactly which cpu was more powerful and while this is good since its easy to implement and fast, this is why its not too battery friendly..

What I did to Sched governor until now: Well no specific feature comes to my mind, but it got optimised alot by backporting amd upstreaming some part of it from higher kernel versions (mostly 3.18)..

Schedutil Governor: Schedutil is the governor every phone uses right now by default I guess. Sched is not even there anymore if I'm not mistaken.

What I did to Schedutil governor until now: Shedutil got backported from 3.18 to the kernel. From my tests, it's been more stable than Sched for below reasons:

o Took less time for the kernel to settle after booting.

o Frequencies stay low and do not jump everywhere when simply looking at the screen.

o Improved latency

Its now possible to switch between them using my app. I wanted to make a comparison between both but couldnt find enough info on them to really tell you precise differences. I can only say Sched is predecessor of Schedutil so I assume Schedutil can only be more efficient.

Load Tracking: Whether its PELT (Per Entitty Load Tracking) or WALT (window assisted load tracking) both increase efficiency since they do not affect frequencies directly and instead of just placing tasks on any cpu it analyzes it and the amount of energy needed for it is estimated. This smart way of doing things make system quicker since it can run more tasks for less energy. This is what EAS is all about.. smoothest UI possible with lowest impact on battery. PELT is more battery friendly as it ramps frequencies up and down slowly.. On the other side, WALT ramps up and down really fast making UI smoother and snappier since every task is done as fast as possible so cpu can idle and go to sleep faster.

What i did to load tracking: I optimised PELT and added WALT.. Its now possible to switch between them using my app.

Comparison between WALT & PELT

Souce: https://fr.slideshare.net/mobile/linaroorg/walt-vs-pelt-redux-sfo17307

Frequency ramp up

[IMG="frequency ramp up"]https://i.imgur.com/ebAL4e5.png[/IMG]

Frequency ramp down

[IMG="Frequency ramp down"]https://i.imgur.com/ClxOjTf.png[/IMG]

As you can see, WALT ramps up way quicker than PELT leading to smoother UI. Also tasks are done more quickly. On the other side, it's also possible to see that PELT may be better is some specific use cases as when another job needs to be done a little after due to it not ramping down frequencies completely. This way, WALT would need to ramp up again while PELT would be ready.

Schedtune: Exposes 2 tunnables to userspace: schedtune boost and schedtune prefer idle into cgroups. There are actually 4 cgroups background, foreground, rt and top-app. The first tunable (schedtune boost) takes an integer between -100 and 100, 0 being the default value meaning the most energy efficiency which means that it will be using the lowest frequency to do what it needs. An higher value will add an % offset to the normally used frequency. The second tunable (schedtune prefer idle) when set to 0 (default value) will simply do what EAS says it to do. When set to 1 it will prefer setting tasks on idle cores to reduce latency. Pretty easy to say the second one is less energy efficient.

What I did to Schedtune: Some improvements to it have been added for sure since first release. I've set top-app

default value to 1 instead of 0 to bias tasks on big cores. This way, it also improves latency for Dynamic Schedtune Boost.

Background has been set to -10 to reduce its impact. Gaming and Gaming+ profiles are using more aggressive values so they are not recommended for other tasks than gaming as this may give you higher battery drain during normal usage.

Dynamic Schedtune Boost: It's pretty easy to understand and its a pretty nice feature made initially by joshuous on the OnePlus 5 if Im not mistaken. It simply sets a user specified value to schedtune boost dynamically a cgroup so it can go back to 0 afterwards to not hurt battery. It's mostly used in cpu-boost for input boosting.. Then why not just use the input boost that worked well on HMP? Well to that I would say: how do you know the input boost frequency value you've set is the correct one for what your specific usage? Input boost will boost to a user specified value but what if that value is okay for chrome but too high for simply scrolling in a text file? Well that's it.. EAS is able to find the frequency needed depending on usage + the dynamic boost it will simply make things faster and smoother by adding a positive offset to the frequency used but dynamically so it can revert back to 0 afterwards and save battery while phone is actually doing nothing or when your simply looking at the screen.

What I did to dynamic schedtune boost untill now:Well I added it to our kernel by backporting the feature from a pixel kernel and adapted it to our phone. Due to some limitation we can only dynamically boost top-app.. at least for now.. I could add other cgroups quite easilly but its not really needed as top-app is the most important/effective one. I'll add more later if its actually needed.

To tweak it: Use the EAS page in my app... make sure you don't set any frequency boost in any kernel manager, tweak input boost ms and dynamic stune boost value. Note: enabling Dynamic Schedtune Boost in my app will automatically erase any previously set input boost frequency so it works correctly.

PowerHAL: For proper EAS people say it needs proper PowerHAL.. The kernel itself cant make what a PowerHAL can do since it cant read some userspace events and all. Lets say boost on input touches can be done with a good PowerHAL so less job is done by the kernel.

What I did for PowerHAL untill now: Well I'm aware of what a PowerHAL could bring tho no PowerHAL has been done for EAS on for old kernels.. That doesn't mean I couldn't modify a newer one to fit our phone but I made a lot of tweaks in the kernel directly to prevent that. A PowerHAL is compiled with a ROM directly so could be harder to replace. So what I did is put some nice features to mimic PowerHAL behaviours like Dynamic Schedtune Boost, DevFreq boost on app launches, fingerprint boost and more nice features directly in kernel that allows (for some of them) to be tuned by the user.

More features and development can be seen in changelogs.

If you have any questions feel free to post them. If I made any mistake feel free to correct me.