[Samsung Infuse 4G] Entropy512:
I have no lag or battery drain other than the notorious UXKG3 lockscreen lag - no kernel can fix that.

I had 92% battery left after 12 hours - most of that was idle time sitting on top of one of my shelves, but still - no excessive drain.

In general without a reproducible test case, or at least enough details on where to start, bug reports like this are not useful. I can't fix it if I can't reproduce it or at least have some very good ideas pointing towards the issue. 90% of the time excessive battery drain is due to a rogue app holding wakelocks when it shouldn't. In the past month I have only ONCE had a reasonably reproducible battery drain issue - On Hellraised ROMs (for some reason, it's specific to Hellraised ROMs), gmail sync will sometimes gulp down battery in extreme weak-signal scenarios (bouncing between 1 bar and no coverage). It happens less often in S7 than others but occasionally still happens. Since committing the cpuidle patch, I've had the above scenario happen again - gmail was at the top of battery usage stats again but battery wasn't dropping nearly as fast as before. (However the root cause was slightly different - it was one of the UCKE3 data dropouts where the radio hung. I may reinstall SensatioN or Matrix VI to have a better test case here.)

As to lag - Lag is highly subjective, I have had no problems with excessive lag. There are plenty of other things that can come into play such as apps reading/writing to filesystems and such - in fact in the past, file I/O is the #1 cause of lag - Hence Voodoo Lagfix. Right now we are at the point where there are no clear file I/O improvements that can be done to get great gains without major tradeoffs. See S.A.S./USAS as an example - that tweak set provides noticeable improvements but not without a drawback, its tweaks GREATLY increase the risk of data loss/corruption. There's a reason I don't run them and don't support them.

Note that the conservative governor's parameters are tunable - it's the Advanced tab in SetCPU, ??? in Voltage Control. The defaults are optimized more towards performance than battery, although there's a possibility that SetCPU or VC may "remember" parameters from a less optimized kernel.

I have:

Sampling rate - 40000 microseconds

Up threshold - 85 (Note: This is more conservative/battery-optimized than default - dropping this makes it ramp up earlier)

Down threshold - 50 (again - battery-optimized. Dropping this makes it stay at higher frequencies longer

Ignore nice load - 0

Freq step - 5% (note: changing this never seems to do anything.)

Already have jhash3 - one of the first things I pulled in. I think - gonna double check that.

I'll look at DC's stuff, but it's fairly aggressive. I will comment on some items:

1) BFS is old news. Its reason for existing is no longer valid. It proved that the Linux kernel had some CPU scheduler regressions, those regressions were fixed, and there is no longer any known test case where BFS consistently outperforms the normal CPU scheduler.

2) ramzswap really is only useful on devices with very small amounts of memory like the original HTC G1, and even then its benefit is questionable. It never gave a consistent provable benefit on xdandroid and the HTC Rhodium has FAR less memory than we do.

I'll talk to LinuxBozo about the ext4 patches. There's also some stuff that might be related to HDMI.