[Samsung Galaxy Nexus] Entropy512:
I did later on in my post - primarily that its design does not take into account the differences in voltage between clock frequencies.

See the part of my post about thinking in terms of "energy per unit of work" - Wheatley could maximize energy used per unit of work in many cases by trying to maximize clock speed, which forces maximum voltage. This is especially bad on kernels that support overclocking, which typically have significantly elevated voltages. An example of a place where Wheatley will break is in a situation where there is a periodic task that fires at an interval longer than the idle residency target. This will cause Wheatley to ramp the clock (and hence the voltage) up to maximum. The improvements in idle time will be offset by the increase in power consumption per unit of actual work done.

It'll also break horrifically if anything inhibits the deeper idle states. Look here for an example for Samsung Exynos (There are similar limitations for Hummingbird):

https://github.com/Entropy512/linux.../master/arch/arm/mach-s5pv310/cpuidle.c#L1308

Note that it does a bunch of operational checks, and if certain features are operational/running, LPA mode is inhibited. Wheatley can't detect these situations.

Edit: Ooops, I was partially wrong on this one - you're only tracking the lowest idle state after looking in more detail. It will still break if there are substates within the deepest state, see above for an example. AFTR and LPA are both part of state1 on all release Gingerbread kernels. The only devices that have AFTR and LPA in separate states are my I777 (for now) and Honeycomb devices.

Wheatley (or at least the concept of trying to hit idle states more often) will work well in operational regimes where static power consumption is a significant factor in power usage, and idle states are hit where power is gated to the point where static consumption is eliminated. It won't work well where dynamic power consumption dominates, as its approach increases energy used per unit of work accomplished.

FYI, the basic concept you have (a desire to hit idle states when static power consumption is a major factor) is why I don't implement 100 MHz frequency support on Exynos - in many cases it increases power usage. Which is probably why Samsung removed that frequency... Taking into account idle states when making frequency decisions is a GREAT idea - but you need to take into account many other aspects of the system too, which Wheatley does not do.

What is unfortunate is that if the CPU manufacturer characterizes their idle states, it is possible to have a reasonably accurate estimate of power consumption by state and use this to develop a very robust governor - but as far as I can tell, Samsung sure as heck doesn't do this (the "power" numbers for idle states are totally bogus) and looking at the code I don't think even TI does (need to run some tests on my PandaBoard.)

Edit: If race-to-idle is so great in so many situations - why isn't it common? Plenty of companies with far more resources and interest in maximizing power efficiency don't seem to be doing this - why? Obviously it is beneficial in some cases (such as 100/200 MHz decisions on Exynos - I'm fairly certain that 200 almost always wins due to idle timing concerns), but if it were beneficial on a wide variety of workloads - someone would have done this quite some time ago.