We are living in an age of amazing portable technology with huge computing power yet some of the software components that manage it are more than 10 years old.

They were created when the concept of portable & battery powered multi core computing was but a dream.

In an ideal world not constrained by thermal and energy factors, the most performant way in terms of user experience and fluidity would be to run all cores on the highest frequency at all times.

In that utopian world, you would divert a good amount of cpu cycles to be used in your apps instead of wasting them on managing thermal throttling, frequency scaling, idle sleeping, turning cores on or off, etc…

Note3 SnapDragon 800

That, in turn, would make the kernel’s scheduler life a lot easier as it would achieve improved performance by working with a fixed number of cores and frequency (all of them at once at the highest frequency) always yielding the same exact cpu cycles per second.

Reality is that we don’t live in this utopian world and instead, all this computing power that fits in the palm of our hands is constrained by thermal, energy and even space factors.

To counter thermal constraints, we have a thermal management code that takes care on it’s own and in a rather primitive & harsh way of limiting the frequency on all cores, once a certain threshold temperature is reached.
That’s your famous & dreaded thermal throttling that can hit the cpu and/or gpu anytime you’re pushing your phone.

Moving on to the energy constraints, we have 3 distinct code paths that independently manage the energy consumption of the cpu (and also gpu, but I am not going to discuss that here).

First we have the famous governor that is an independent code within the kernel that is tasked with dynamically adjusting per core frequency by periodically calculating the load percentage per sampling period (wall – idle = load).

Created in 2001/2003…

In a perfect world, the most optimum frequency would be the lowest one that could achieve a 99% load per sampling period because the lower the frequency, the lower the voltage and in turn, energy & temperature are lowered.

Next we have the hotplug code that is also independent and tasked with turning cores on or off depending on the system load. Usually the hotplug code decides when to turn on or off cores by periodically checking the run queue against a fixed set of hard coded thresholds.
The run queue, that is managed by the scheduler, is the amount of outstanding threads waiting to be executed.

Intel 486, looks so simple now…

In it’s essence, a cpu is nothing more than a glorified (I am oversimplifying so please forgive me!) but quite complex calculator that (in the Snapdragon 800) can run one task per core (or thread/program if you want) at a time. To give the illusion that a cpu is running many programs concurrently, the scheduler switches almost instantly from one task (thread/program) to another (in the realm of a few milliseconds per thread/task).

And to finish, we have the famous scheduler. As you already have read, it’s purpose is to manage all the tasks/threads/programs by allotting them a slice of cpu time. It’s a complex & dynamic piece of code that has to juggle a lot of variables like the amount of cores available, how to prioritise tasks, how to distribute tasks across available cores (load balancing), dynamic priorities, preemption, etc…

We currently have five distinct code paths (thermal, cpu governor, gpu governor, hotplug & scheduler) independently trying to manage our cpu.
So instead of having one unique captain managing our cpu, we currently have 5 that don’t talk to each other and are constantly making decisions to suit their own needs.

I think we, as users, don’t need to waste our time trying to “tweak” all those flashy & exotically named governors to adapt them to our conflicting needs of smoothest experience with best battery life.

Most if not all of these flashy & exotic governors are based on the same old ones. A bunch of them just changed some parameters while others added some “booster” code to try and compensate for their deficiencies. With all of them it is always a matter of compromise; people waste a huge amount of time trying to find the “perfect tweak”.

The same goes for the Hotplug managers out there, some flashy and some classical but most (if not all) are based on the same principles.

We all assume that a good captain has to be deeply knowledgeable of his ship and crew yet we are still using the same old and deprecated governors across all of the android hardware ecosystem.

I coded PrecoGOV from the grounds up to be the sole decision making captain of our smartphones.
Once you activate PrecoGOV it takes over and dynamically adapts to your usage pattern.
That’s why there are no cryptic parameters to tweak and no tradeoffs to choose as it’s sole aim is to give you the best & smoothest user experience while maximising battery life as best as it can.

To achieve such goal, PrecoGOV manages the frequency, idle & sleep patterns, hotplugging, temperature per core and even gpu and tries to help the scheduler as best as it can, all while taking into account battery and thermal constraints.

Each core manages itself but makes decision based upon the collective and can ask other cores for help.
PrecoGOV adapts to what you are doing and knows what is most important and critical at that instant. It leverages all the hardware available in our Note3 to anticipate what you will be doing next.

For example, it knows when you are going to touch the screen before you actually touch it.
PrecoGOV also knows when there is activity that you care about and is there to make it the smoothest experience possible.

It also manages the thermal envelope so when a core hits a threshold, PrecoGOV starts to sample it’s temperature very closely and if it goes high enough, PrecoGOV will start a dynamic frequency flip flop algorithm just enough to bring that core back to a safe upper limit, while the rest of cores continue to work unaffected at peek performance.

PrecoGOV also has a one of a kind direct jump frequency algorithm that computes the best frequency to instantly jump to for a given load.

Each core computes and manages it’s own independent and variably adaptive sampling rate that tracks user behaviour.

The hotplugger’s unique algorithm takes into account the number of cores, cpu load, per core run queue, available battery, previous/current trend, dynamically computes a run queue threshold and decides to bring a new core online or not.

Version 0.9 of PrecoGOV is bringing a lot of smart & innovative algorithms that cooperate in harmony to make the most out of the Note3’s battery life while bringing the smoothest user experience possible.

I still have a lot of exciting features to incorporte in the upcoming versions that will make PrecoGOV even more unique but I wanted to share with all of you what PrecoGOV is already able to achieve!

The upcoming ShinTo Kernel “Second Reality” won’t be for the faint of heart, those that obsess over SOT or those stuck in the old ways… To them I say “Move along”.