I disagree on conservative being worst for battery - It has provides spectacularly good results on the Xperia Z and Tablet Z, and also did so well on the find5 that it became the default in CM10.1. (Ondemand performed very poorly)
It really depends on how you tune it - if you're not careful you can bias it too aggressively towards increasing frequency. The biggest improvement possible for conservative is to reduce its polling rate - there are multiple ways of doing this, but in my opinion the best method is to port over some of the improvements that mainline Linux did to ondemand but forgot to put into conservative - This uses an approach known to have been accepted to mainline in the past and respects any hardware limits that might be in place.
is one such example.
I'm a battery whore so I typically tune conservative aggressively towards saving battery - 90% up threshold and 40-60% down threshold.
Seriously, users should look into the various tuning parameters of their governors and understand what they do. 90% of the improvements possible by changing governor can be achieved with a combination of userspace tweaks and minor governor tuning tweaks (other than the above fix for conservative - conservative sucks without the above patch.) I don't know how many times a governor has been called "awesome" when it was no different from an existing governor other than different default tuning (Lionheart is a perfect example of this... It is 100% identical to conservative with the minimum polling interval hardcoded to 10ms and default up/down thresholds changed.)
Also, the primary historical features of smartass (screen on/off thresholds) are obsolete. You've been able to do this efficiently in userspace for ages. It made sense when the max speed of a CPU was 600 MHz and you needed to change limits as early as possible in the wakeup cycle, but these days you can get nearly all of the benefits of smartass by using SetCPU's profiles feature and setting different screen-off profiles. Google has even integrated this kind of functionality into Android with the Power HAL (warning: You might wind up finding your governor fighting the power HAL if the kernel author wasn't careful...)
(back in the day, my favorite configuration on the Galaxy S2 and Note was a screen-off max of 500 MHz, and a screen-on minimum of 500 MHz - this would greatly improve responsiveness with minimal battery impacts as the voltage for 500 MHz was only slightly higher than 200 MHz. On a device with even basic working cpuidle, you want to pay more attention to how voltage ramps with clock than the raw clock gate, since any modern ARM CPU can at a minimum clock-gate efficiently when idle. Deeper idle states powergate the CPU but these often get locked out in many cases, such as when more than one core is online with nearly any multicore device except the Snapdragon 800 and maybe the 600. Not sure about the quad-A7 400s.)
*so much sig updating needed*
My Github profile - Some Android stuff, some AVR stuff
An excellent post on "noobs vs. developers"
A few opinions on kernel development "good practices"
Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
<Entropy512> gotta be careful not to step on each other's work. :)
<Bumble-Bee> thats true
<jerdog> compeete for donations