(If you own a Nexus 5X or 6P and you are too lazy to read the philosophy of this technique, head on down to the 2nd post and pop those values into your kernel manager and be happy. If you own a different device, please read this post in full.)

The Introduction

*At least on the Nexus 5X, you shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.

The Nitty Gritty

Nominal Clock Rates

Efficient Clock Rates

Clock Rate Biases

Idle - 384Mhz

Page Scrolling - 600Mhz

Video - 787Mhz

App Loading - 960Mhz

High Load Processing - 1440Mhz

Idle - ???Mhz efficient / 384Mhz nominal

Page Scrolling - ???Mhz efficient / 600Mhz nominal

Video - ???Mhz efficient / 787Mhz nominal

App Loading - ???Mhz efficient / 960Mhz nominal

High Load - ???Mhz efficient / 1440Mhz nominal

The Set Up

most efficient

above_highspeed_delay

highspeed_freq

above_highspeed_delay

above_highspeed_delay - 20000

frequency:delay

above_highspeed_delay - 20000 460000:60000 600000:20000

highspeed_freq

target_loads

highspeed_freq

The Money Shot

If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***

(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)

above_highspeed_delay - 20000 460000:60000 600000:20000

20000 460000:60000 600000:20000 boost - 0

0 boostpulse_duration - 80000

80000 go_highspeed_load - 99

99 hispeed_freq - 600000

600000 min_sample_time - 30000

30000 target_loads - 98 460000:19 600000:80 672000:12 787000:81 864000:9 960000:69 1248000:95 1440000:95

98 460000:19 600000:80 672000:12 787000:81 864000:9 960000:69 1248000:95 1440000:95 timer_rate - 20000

20000 timer_slack - 80000

Optimize Idle Frequency

timer_rate - If your idle frequency is not being exceeded much , adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often , adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.

, adjust this downward in increments of 5000 until it is, then increase it by 5000. , adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency. above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.

Enhance Task Responsiveness

above_highspeed_delay

target_loads

Find Optimal Loads

target_load

(clock rate * 0.9) / next highest clock rate

(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)

(1 - next highest clock rate / clock rate) * -1

(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)

384000:75

460000:69

600000:80

672000:76

787000:81

864000:81

960000:69

1248000:78

384000:0

460000:19

600000:30

672000:12

787000:17

864000:9

960000:11

1248000:30

1440000:15

384000:72

480000:68

633000:74

768000:80

864000:81

960000:69

1248000:83

1344000:84

1440000:84

1536000:84

1632000:86

1689000:83

384000:0

480000:25

633000:32

768000:21

864000:13

960000:11

1248000:30

1344000:8

1440000:7

1536000:7

1632000:6

1689000:3

1824000:8

Using Optimal Loads

target_loads

target_loads

Fix Stuttering

min_sample_time

min_sample_time

min_sample_time

But What About That 2nd CPU?!

384Mhz

1248Mhz

1824Mhz

The Money Shot: Part Deux

(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)

above_highspeed_delay - 20000

20000 boost - 0

0 boostpulse_duration - 80000

80000 go_highspeed_load - 99

99 hispeed_freq - 1824000

1824000 min_sample_time - 20000

20000 target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95

98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95 timer_rate - 20000

20000 timer_slack - 80000

What About Bob Touchboost?

The Conclusion

You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.

This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking. I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.

I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.

I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized Nexus 5X running ElementalX Kernel, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.

I'm about to tell you how to get buttery smooth, lag free performance withgood battery life, using an old school governor featured in practically every kernel...Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!This isn't a guide to get 36 hour battery life.... That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past.Without compromising, you can get 7-8 hour screen on usage with(Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)However, it should be noted that this doesapply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum.optimizations are up to you.After a bit of tweaking and experimenting, I developed some settings that provide absolutelybattery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even a Nexus 5X. This will work onROOTed phone with the Interactive governor!So, after writing a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Nexus 5X you can useEnough long winded preamble! Let's get down to...Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on abasis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.To understand what's best under a variety of tasks, we have to identify two types of load profiles:andNominal clock rates are theCPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn onCPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)For example, on my Nexus 5X, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are460Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus,Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.Using the information provided above, figure out both yourfor the tasks you perform most often and yourdepending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:With this done, you will want to start the fine tuning phase! Correlate thewith their closest, similar to below:Keep these handy, as they're going to be necessary for...Now that we know what are thenominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary.In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate,We have two primary goals:and. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that isincluded in those summaries: multiple frequency adjustments.Thesetting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set inFor example, we want theas low as possible to get the CPU out of the idle state as quickly as possible when aload is applied. However, wewant it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)But at this point we're not ready to take on aprocessing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just settingwe will instead use the format "" to setThis tells the Interactive governor to hold out 20ms after our target load when it's at our(which we're actually using as ourfrequency--a burst frequency as originally intended),it tells the governor to hold forafter it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with thesetting in a minute. And if you don't know what I'm talking about when I say "" then you didn't go search for the basic Interactive governor settings and read about it!These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background,Background and idle tasksbe limited to thereasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that youneed performance for.So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...If you've made it this far, you're ready to put these strategies into play!With that out of the way...If you are using a Nexus 5X, use the following Interactive governor settings("little"–the one with 4 cores) and then tweak with the instructions below:These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values.Anything more than about 15-20% idle CPU use at any given timenegatively affect the results you see without further tweaking!Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency, and adjust the following:The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device.Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in bothandupwards to the next available clock rate until that task is smooth.If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop),If the task is smooth(or after) it slows down, then you have reached your optimal clock rate and can move on.Now here's where we get a little math-heavy to determine what the optimalfrequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)For the, we want to correlate a load value90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:For the, we want to correlate a load value at which anythingwould be better served by a higher clock rate. To calculate this:For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:For the Nexus 5X, theof CPU 1 are:For the Nexus 5X, theof CPU 1 are:For the Nexus 5X, theof CPU 2 are:For the Nexus 5X, theof CPU 2 are:Now, you might be asking,Well, we had put some values intoearlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible,. For each frequency tagged as our nominal clock rate, we want to use thein. For everyfrequency, we want to use ourvalue.We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it isefficient to do so. For all the nominal clock rates, wethe CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequencythey overwhelm the current frequency.All said and done,Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of(minor) battery life by adjustingup in increments of 5000 until you are satisfied.change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value ofHowever, this stepif you properly calibrated your maximal and minimal efficient loads!So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.But itgood for one thing thatusers do pretty frequently...Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be ourprocessor–we want it to come into play spontaneously andduring tasks that necessitatehigh loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:In this case,, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhzwhen needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and medianclock rate, using the instructions previously.For the Nexus 5X, we'll jump straight to...If you are using a Nexus 5X, use the following Interactive governor settings("big"–the one with 2 cores)Touchboost is a nifty feature in a lot of kernels (including stock on Nexus 5X) that jumps up the frequency so that you experience minimal lag. However, with all the above settings,We generally want to keep the CPU on thepossible frequency, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the 2nd CPU core,If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable. On the Nexus 5X, touchboost addsperceptual performance gain andhurts efficiency and battery life. If your kernel doesn't allow you to turn off touchboost, try another one, like the excellent ElementalX Your battery life will thank you!I have achieved unprecedented performance, smoothness, snappiness, and battery life. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different.If it is not optimally tuned, performance and battery lifesuffer! If you're not seeing buttery smooth, snappy performance,However, if youhave superb performance (and you tweaked the values conservatively andin large steps), then youalso get the aforementioned battery life.I will be happy to answer any questions, or provide any guidance I can. However:Lemme know what you think, and good luck!