[Galaxy S III Android Development] ffolkes:
Thanks for the quick reply. I look forward to v0.8. :) But I have already done more than mess with the beast. :P

I added ZZMoove to my kernel months ago, but never used it because I was into PegasusQ and had made modifications to it (not to mention AndreiLux's additions to it). However once I saw how well documented and actively developed ZZMoove is, I decided to switch over by default. You guys have done a great job with it. :)

Since then I have noticed more stability, and no more SOD. :good: However a lot of users reported lag issues, enough so that they were going out of their way to choose a different governor. :( I personally like ZZMoove, but I added some extra tuneables to help. So far they all seem to be working well. If you have any use for them, you are welcome to use them. :) Also, I had to rearrange some .attr's because apps like SetCPU set the tuneables as it reads them from sysfs, so it would set them in such a way that they would sometimes fail ZZMoove's input sanity checks and therefore never get set.

As always, all can be disabled or ignored with 0.

fastdown_freq - Frequency threshold above which there is a different up threshold applied.

.

fastdown_up_threshold - The up threshold used while fastdown_freq is exceeded.

.

responsiveness_freq - The frequency threshold below which a different up threshold, and/or sampling rate will be applied. The opposite of fastdown_freq. Similar to "freq_for_responsiveness" in PegasusQ. This greatly helped eliminate all lag issues. early_demand helped, but wasn't enough. With the default sampling rate of 100ms, and the conservative nature of ZZMoove, after a short pause in interacting with the device the frequency would hit 200 MHz. Then once a user touches it, it could take as long as 100ms before the governor would even do a check, then maybe even another 100ms to bump the freq high enough to eliminate lag. 200+ms is very noticeable to most people. With the two tuneables below, lag can be drastically reduced with just the governor, and not relying on a touchbooster or anything like that.

.

responsiveness_up_threshold - The up threshold used while below responsiveness_freq. Disables itself on sleep. Can be set to 0 to disable this check so you can choose to use only responsiveness_sampling_rate if you prefer. I find 400000 works well.

.

responsiveness_sampling_rate - The sampling rate used while below responsiveness_freq. Disables itself on sleep. Can be set to 0 to disable this check so you can choose to use only responsiveness_up_threshold if you prefer. I realize increased sampling might affect battery life, but I hope it will be negligible. I find 70000 works well.

.

multicore_engage_freq - I'm not really sure how useful this is. When I used PegasusQ I was able to get it to very tightly control the cores (I liked to heavily bias just one core), but when I first started using ZZMoove I noticed I couldn't replicate that. I think ultimately it my fault, as I was new to ZZMoove and probably setting it wrong, but I added this tuneable anyway. It provides a simple way to prevent the hotpluging logic from adding any cores while the current frequency is below multicore_engage_freq. I think I mainly left this in because it made me feel like Captain Picard every time I read "engage." :cool:

.

hotplug_down_block_cycles - The opposite of the existing hotplug_up_block_cycles.

.

hotplug_max_limit - The most cores that can be online at any time. Instantly enforces and turns excess cores off.

.

hotplug_min_limit - The least number of cores that should be online at all times. Instantly enforces and brings the requested cores online.

.

hotplug_lock - Lock the core count at exactly this many cores, and never change it. Mainly useful for debugging, testing, and benchmarking.

Here are my commits.

I'm currently working on some rudimentary core state accounting, so power users can see what core usage looks like over a definable period. In doing this I have noticed that out of the box, ZZMoove brings up all cores on every hotplug-up decision since they are all set the same. This seems a bit inefficient, is it done on purpose?

Thanks for all the work you guys have done! :D