[ONE Original Android Development] schaggo:
I reread my message from yesterday night (~1am) and realised it sounded kind of off. No disrespect was intended, I guess I was tired and grumpy...

Anyway, digging through some smartmax code by maxwen (https://github.com/maxwen/enrc2b-kernel-BLADE/blob/master/drivers/cpufreq/cpufreq_smartmax.c) I found the following:

* CPU freq will be increased if measured load > max_cpu_load;
* CPU freq will be decreased if measured load < min_cpu_load;

And some sample values in the code:

#define DEFAULT_MAX_CPU_LOAD 80
#define DEFAULT_MIN_CPU_LOAD 50

Render defaults are 55 and 5 respectively. This means the cpu will ramp up at or above 55% load and ramp down at 5% or below. As 55 is reached quickly and 5 is reached only rarely, the CPU will jump more often to and remain at higher freqs longer than really needed. This is probably and foremost why it feels so smooth [MENTION=788951]LiquidSolstice[/MENTION]. I reckon a similar smoothness could be achieved with lowering the values to achieve greater bettery life though. My personal setup is 85 max_cpu_load and 45 min_cpu_load.

* The "ideal" frequency to use. The governor will ramp up faster
* towards the ideal frequency and slower after it has passed it.

As a side note, Render defaults are set at 146MHz which is an artifact, as 146MHz is not a valid step anymore since the rebase where 300MHz is the lowest speed. Apart from that, going by the Smartmax ramping logic, the "ideal frequency" concept is defeated as now it is per default set to the lowest frequency available. The concept - as I understood - should be to use an intermediate, somewhat power-efficient but still performant enough freq step to achieve fluid operation but keep energy consumption in check. Smartmax tries to hover around this frequency as often as possible. It jumps straight up or down to it but then is somewhat reluctant to overshoot and spike or to immediately drop too far below it. Kind of like a cruise-mode-gear in a car or so; keep it steady, keep it going... ;)

When below the ideal freqeuncy we always ramp up to the ideal freq
When above the ideal freqeuncy we always ramp down to the ideal freq.

Going by that, the default setup will produce heavy freq shifting with lots of spiking. Explanation: because Smartmax will always ramp down to the ideal freq, so from any freq the CPU currently sits at, it will go down to 146MHz straight whenever possible. On the other hand, whenever load occurs, it will always ramp up to the ideal freq which is... well it is 146MHz, which is the lowest freq available. So in real life things will probably look somewhat like this: due to Input boost, the CPU will jump to around 1200MHz, then find the load insufficient, ramp down straight to ideal which is 146MHz, then find the CPU to be underpowered, then ramp up to... well to ideal which is 146MHz, then re-evaluate and still find the CPU underpowered at ideal and then start to spike to whatever value there is, probably something around the 2000MHz mark. But then again, re-evaluating load, find itself in a situation of underload and jump down to ideal, 146MHz again, only to again be underpowered and spike again... repeat at will.

Anyway, some example values defined for ideal freq in the source code for then-current devices, when Smartmax was written (2013, that is):

#define DEFAULT_AWAKE_IDEAL_FREQ 806000 (HTC One X [I believe, codename Primo U])
#define DEFAULT_AWAKE_IDEAL_FREQ 5940,00 (HTC One M7)
#define DEFAULT_AWAKE_IDEAL_FREQ 702000 (OPPO Find5)

As none of the examples uses a similarly low freq as Render defaults, I deducted from the max freq and the defined ideal freqs for the respective platforms, that for the Snapdragon 801 in the OnePlus One a comparable freq would be somewhere in the 800-1200MHz range. Truly intermediate, so to say. In my personal setup, I chose 1036MHz as to me it seems to be a reasonable step looking at performance gain vs additional power requirements per additional step.

The default suspend_ideal_freq seems reasonably set, except that it doesn't exist either in the rebased kernel. 422MHz would be existing, 499MHz does/is not. When looking at the power requirements by freq table though, 300MHz to 652MHz runs on the same voltage, 729 only marginally higher, so in my personal setup I chose 729 as ideal suspend freq for the same reasons as above.

Concerning touch_poke_freq which is set to 1267MHz while the CPU Boost driver input boost value is set to 1190, in my book, this means Smartmax will overpower the CPU Boost driver and input boost effectively happens at 1267MHz instead of at 1190MHz. So I have set this value to 0, to only use CPU Boost and not Smartmax boosting. For strict UI smoothness an even lower value could probably be used, I'm happy with the default 1190MHz though.

To further tune the freq ramping towards battery friendliness, I modified the ramp_up_step and ramp_down_step. By default these are set to 200 up and 200 down I believe. They come in place when ramping up above ideal freq or when ramping down when below ideal freq. Totally arbitarily I chose 150 for up and 300 for down. That is, to achieve a bias towards faster ramp down vs ramp up. It basically makes the CPU reach lower speeds quicker than it reaches high speeds, thats all. As different frequency ranges are affected, they do not directly interact and 200/200 would be fine as well, I guess.

Additionally to the tunables, I have undervolted, underclocked (although msm_limiter interferes here and regularily resets max freq to 2500MHz) and underclocked GPU as well. I also use msm_mpdecision (aka bricked hotplug, right?) instead of the default msm_hotplug as in my tests, msm_mpdecision was more willing to run multiple cores on low-to-mid frequencies (coupled with my Smartmax setup) where msm_hotplug seemed to rather let one core spike instead of turning on additional cores. Having done a lot of online-studies (yes, yes, I know...) I am led to believe in multi-core-low-freq is to be preferred over single-core-high-freq on modern CPUs, hence this choice.

This post was btw open and almost finished since Friday evening, I never got around submitting it though. But here it is and it may or may not provide some value :)