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

I have been summoned!!! lol j/k ;) Just been busy but hope to be lurking the threads once again. So let's get into this:

Not only is there a touchboost value. There is a top-app schedtune.boost value as well. I believe by default it is set to 10. This means that top-app tasks have their capacity increased by 10%. So if a top-app tasks needs 1000MHz, it will actually use 1100MHz with the top-app boost. This is to make sure these special tasks get reserved bandwidth in a sense. SO this is why it will boost past that value you set. Also you will want to make sure that both freqs are the SAME. This is to make sure tasks migration works as smoothly as possible. IF a tasks is running on the core with 694MHz, and it wants to pass it off to a little core, the new core has to be AT or HIGHER frequency. So you can create latency during task migrations (which happen ALL the time on EAS and even so for HMP). This is why you see the default boost values used on stock roms match. Task migration is even more important on Big.little SOCs.

I don't have an issue with overheating at all. But usecase is important and you must have a different usecase than I. I use my phone for work and play, I stream music over BT all the time, and stream videos with YouTube. I will remark on your usecase below:

I wake mine and its at 27C and sticking. Does your phone idle after waking? I use DevCheck and use the overlay. It isn't aggressive with its polling and gives an accurate reading. I can see that I idle perfectly fine via Vertex. Can you give me all the values you are using for vox here: /dev/voxpopuli ? I am interesting in your boost value. Also, can you get me a copy of your init.rc and init.qcom.rc files? I want to see the default values there. There is a different in the top-app boost value when idle and during interactions (touches) and I want to see what it is at idle. Because if it's too high, you will never idle. And since its AEX I cant see it.

Honestly, I think something is really wrong with your setup. I am not trying to jsut place the blame on something else but I have been building this EAS kernel for months now. I have never had issues with overheating. So I think something else s either causing your freqs to stay too higher, or its something else but I think it's the latter. I want to help you though.

Could be an issue caused by AEX. Not sure. One thing for sure is I use my phone heavily and the only time I get any heat is when using google hangouts and making calls through wifi. That's it.

Once again, I think something is wrong rom or app side, not kernel side. But with that, EAS has ALL control over freq jumps. If it jumps, it is doe to the task needing that particular freq till the task is done. With HMP, they use timers and the poll the load from the scheduler to guess what freq and timer to use. This means that it's doing nothing but guessing the freq needed. Most times it overshoots to prevent latency. This is one reason EAS came about. I wrote a lengthy post about it in my own kernel thread HERE. But if your phone is using higher freqs longer than normal, you will get heat. This is why I am suspecting the rom settings for touchboost and stune, rather than the kernel. Stune gets set in the ramdisk and altered by vox populi. So I am really interested in seeing what your values are.

Sorry for the confusion, there is so much to take in with EAS. EAS has every advantage over HMP. I am able to have a more fluid experience and even a bit more battery life without ANY sacrifice. If I tried to do the same with HMP, I would lose more battery to gain the same performance and visa versa. Also, EAS was designed to not need any realy tuning like HMP. Throughout HMP there are hints that do this and hints that do that, and interactive uses different hints to do its own thing. The number of tunables doesnt make a kernel greater, nor does it make it performance any better. EAS is designed for the MOST optimal task placement and capacity measurement. RIght now there are two different ways tasks get quantified and that is WALT (Window Assisted Load Tracking) and PELT (Per Entity Load Tracking) WALT is from CAF and is more interactive with the tracking and the values it gives. This means that it can respond faster to different load changes. PELT is using CFS from Linux and uses Decay. Kinda hard to explain but it gives a more stable measurement. So when there is a sudden drop in load but then goes backup, it may carry the freq through that period where WALT may have been tricked for the short period. But either or works better then a tuned interactive governor with HMP scheduler. As I favor performance and smoothness over straight battery. Why use your phone when it's janky all the time. As long as I can get back to my charger at the end of a long day and still have enough to idle through the night if I forgot to put it on my charger, that's more than enough.

Sorry for the headache, I am sure there is a reason why you are having a problem that others are not. If it were the kernel, it would do it for everyone that uses it. So for me that points to your Rom or an app(s) you my have installed. Can I get a screen of your time in states stats? You can use EXKM or Kernel Adiutor and as a reminder, can you tell me if your phone can actually idle? like stay at 307MHz. And lastly, I apologize if I missed it, but what model phone do you have?

Thanks!