[OnePlus 3 & 3T Cross Device Development] RenderBroken:
S-s-super post!!!!!

Hopefully we are paving the way for other roms to enjoy EAS via my OOS-EAS kernel I am working on. I said I would do it and so I will.

Thanks for the kind words. EA is really cool in that it quantifies tasks in such a way that it knows how much capacity (frequency) to give a task. Sometimes, tasks can be measured incorrectly. There are tools to test such things such as the LISA Toolkit from ARM. I have used this tool to see if how I have setup EAS passes a number of tests/scenarios. The tests are synthetic workloads of different size tasks, with different execution lengths, etc. I can say that so far, I have been able to pass these tests more than a majority of time. I believe there are seven tests in all. But it isn't bulletproof. There can be apps that have different threads that misbehave in any number of ways. I believe EAS is working correctly in that in the scenario above it sees the different tasks and is trying to complete them in the way it knows how. There is alot going on while browsing, you have the browser app itself, you have different things going on such as videos or adds loading, and not all done under the same app/task. Many tasks in fact, and unfortunately, you see what happens is higher freqs have to be used to work those tasks. ATM, EAS is fantastic and in my own usage, it far exceeds HMP. I prefer performance over battery without needless wasting. EAS Does this for me and when I browse, I don't always get higher freq usage like you do, but I sometimes do. It also depends on the website. EAS is getting smarter each day in how to handle a number of different scenarios. I am sure there are other ways to improve such freq usage. See below fuch such an example.

I wouldn't call the jumping needless. EAS is working on the tasks being placed at that moment. Luckily, it doesnt use times like HMP/Interactive so as soon as the task is complete, it will jump back down to current workload/task capacity. Just because the streaming is done full screen doesnt mean the browser and the website are in the foreground and forgotten. There is still alot going on that EAS is working on. Still see even further below for a possible change that might help ;)

So, up/down ratelimit. These are easy to explain enough. With SCHEDUTIL it runs an equation for picking the next freq. That's all. This lowers the overhead usually generated by governors like interactive that have to decide the best frequency to use and what timers to use. In EAS we do not have to do this. The SCHEDULER is the one calling the shots now. This is the whole point of EAS. Why over complicate things. The scheduler is the best place to truly quantify a task and to give it weight. The scheduler is where load is generated. It is in the best position to decide what frequency a task needs for the most energy efficient completion. So with this information, it gets passed to SCHEDUTIL and SCHEDUTIL runs the equation to decide next freq. Now this is where the up/down ratelimit come in. By setting the Up ratelimit we decide how often to run the equation for deciding the next higher freq. default is 1000us so this is also 1 millisecond. I set this to a lower value. This means that is will ramp up faster than default. By setting a higher value I am slowing down how fast the frequency raises. If I set too low of a value, this can also raise overhead and can hurt performance. By setting too high of a value, we can make SCHEDUTIL not "interactive" enough to handle task completion and can generate jank. One thing to keep in mind is the magic number of 16ms. 16ms is the number that Google says we should complete a frame. If we go over that number, you will see jank. So with 16ms in mind, if we leave the stock settings of 1000us(1ms)this means that the governor will select the next freq 16 times within the acceptable time frame.

With Down ratelimit, the smaller the number, the faster is scales the ferq down. The larger the number, the longer it stays at a higher freq.

See below about schedtune.prefer_idle

In EAS, it is mostly more energy efficient to place tasks all on the same core (Mostly CPU0). This means that the big cores don't need to come out of sleep (CSTATE). But this is not good for general throughput as tasks have to queue up. This was also the train of thought back on older 3.4 based kernels but they found it was causing other unseen problems. With EAS, we can force new/waking tasks onto idle cores instead of packing them on the same core. This means that there will be many threads and tasks being worked at one and thus have better throughput. So using prefer_idle=1 means we want those tasks (whether foreground tasks or top-app tasks) to be able to use ANY idle core for working tasks. We DO NOT want background tasks to use prefer_idle so we set it to 0 for those tasks. We want those to pack on the same core, mostly cpu0. This is also one reason why ppl complain about deep sleep on the small cores. Most apps are polling CPU0 and CPU2 for information such as frequency used and time-in-states. since we have background tasks set to not prefer-idle, they pack CPU0 thus never allowing it to get to deep sleep but ALSO allowing the other cores (mostly BIG cores) to get into deep sleep. Thus saving more power than the old way. So when someone asks why small cores don't get alot of deep sleep, this is why. We save much more power letting the BIG cores stay in deep sleep and allow the small cores to do all the background work and such. This also has a side effect of better throughput than on HMP. This is also why on EAS you generally have a smoother UX but get the same battery life of HMP kernels. OF course I could try to squeeze every bit of battery life I can but whats the point in having a nice phone if I hobble it and get a less than pleasant UX(User Experience for those that don't know).