[Sprint Samsung Galaxy S III] decimalman:
First and foremost, dmservative is a battery-saving governor. I would like it to perform well, but I haven't spent a lot of time wringing better performance out of it. I'll sit down and figure out some more responsive tunings in a bit.

@mw86: for frequency adjustment, I don't do any calculations based on freq_step. Instead, I make an estimate based on current load (as percentage of current frequency) compared to the up and down thresholds. When load increases, frequency jumps to target down_threshold% usage (and up_threshold for decreasing), so with your configuration it will jump from min to max and back with nothing in between. With the default configuration, you should see some spikes at frequencies around 700 and 1000 MHz.

The ideal that you mentioned early in your post is much more like ktoonnservative in operation. If you wanted to tune for that, that's the governor to start with.

Hotplug thresholds are based on max freq, but freq thresholds are based on current freq.

@freecharlesmanson: sampling_rate is a time in microseconds between each sample, so with default configurations, I sample about 1/8 as fast as ktoonservative, and change frequency in one single step rather than a series of smaller steps.

The changes you mentioned to ktoonservative will not give the behaviour I'm looking for. I wrote a new governor because the target I wanted to tune towards could only be approximated by ktoonservative.

EDIT: Now that I've had some coffee, I think I can do a better job explaining the advantages of dmservative over other governors. Hopefully this will help explain where I'm coming from with dmservative, why it's tuned the way it is, and why I keep saying not to touch my precious tuners. :silly:

This is a power-saving governor first, so I've done a lot of benchmarking to tune for optimal idling, both in and out of load. When I say that dmservative aggressively hotplugs, I mean it: when core 2 will do nothing but waste power, dmservative turns it off. When it's necessary or (presumably) more efficient to turn it on, dmservative will do so. The two tests for this behavior I use most frequently are YouTube video and extended periods of screen off.

YouTube: from what I've observed most other governors (ktoonservative included) keep core 2 mostly on, even though about 90% of the time one core or the other is sitting in WFI and wasting power doing nothing. dmservative reduces that to around 50%. The recent changes I made to keep things smoother have caused some regressions on this front (it used to be about 20-25%), but the difference is obvious. Beyond idling correctly, dmservative chooses lower frequencies dramatically more often than other governors. Quick tests, 60sec each:

state	dmserv	ktoonserv
c1wfi	29.41	29.59
c2wfi	1.22	24.73

freq	dmserv	ktoonserv
384	12.16%	1.78%
486	8.33%	5.15%
540	14.91%	0.00%
594	6.63%	8.28%
648	11.31%	8.41%
702	3.70%	0.00%
756	9.33%	8.60%
810	6.02%	6.30%
864	3.72%	7.26%
918	4.32%	0.00%
972	1.35%	6.82%
1026	1.33%	8.28%
1080	2.62%	0.00%
1134	3.00%	9.60%
1188	1.33%	5.38%
1242	2.68%	7.75%
1296	0.67%	0.00%
1350	2.00%	4.60%
1404	0.00%	4.71%
1458	1.00%	0.00%
1512	3.58%	7.07%

Screen off: relative to other governors, dmservative reduces WFI & retention state usage on core 1 by about 15%, keeping the processor in standby for longer. Core 2 WFI is reduced by around 70%. This is one area where I absolutely want to race to idle: the faster computation completes, the sooner the processor re-enters its zero-power state. dmservative succeeds in this, decreasing total online time by 10% or so, and keeping core 2 off while it does it. Quick test, 300sec (+/- a bit while wifi adb wakes up):

state	dmserv	ktoonserv
c1wfi	2.55	2.96
c1ret	20.88	25.26
c1susp	270.3	266.59
c2wfi	0.51	1.7

I don't recommend tweaking the tuners because they work together to form an simple, predictable frequency ramp: 384 -> 648 -> 1080 -> core 2 online -> 1512. Less-than-maximum load will break out of this ramp and avoid turning on core 2. This concept is the core of the dmservative governor, and while it's very simplistic compared to other governors like pegasusq/SLP, it's effective at what it does when tuned optimally. Changing the tuners is probably best done with some understanding of how they're related to this ramp, and it would help if I explained what's happening under the hood.

If usage% (compensated to max_freq) > hotplug_up_threshold%, core 2 is turned on

If usage% (compensated to max_freq) < hotplug_down_threshold%, core 2 is turned off

If usage% > up_threshold%, frequency is adjusted to >= current * usage / (down_threshold / 100)

If usage% < down_threshold%, frequency is adjusted to <= current * usage / (up_threshold / 100) (there's a little more to this one, but it's not relevant ATM)

Assuming a very high (99% or so) load, we can calculate different ramps and determine at what point in the ramp to turn core 2 on, which will adjust power vs performance accordingly:

down_threshold 40, up_threshold 80, hotplug_up_threshold 62: 384 -> 972 -> core 2 online -> 1512

down_threshold 70, up_threshold 80, hotplug_up_threshold 80: 384 -> 594 -> 864 -> 1242 -> core 2 online -> 1512

down_threshold 70, up_threshold 80, hotplug_up_threshold 55: 384 -> 594 -> 864 -> core 2 online -> 1242 -> 1512

The downward ramp should always quickly and accurately reduce frequency, but as the up ramp gets more aggressive the processor will naturally spend longer in higher frequencies.