[One (M7) Original Android Development] dictionary:
I love it lol.

http://xdaforums.com/nexus-4/general/kernel-moob-t2549750/page67

" Preservative

This is just for the record, and for those interested. The previous version of Preservative worked like a combination of smartass and conservative. It would scale straight up to the optimum frequency if there was any load (like smartass), then scale up one step at a time (like conservative) if the load was above the required threshold. This worked pretty well, and helped keep the frequency low. But sometimes it was keeping it low for too long, and a few users (myself included) noticed occasional hangs, presumably caused by a pile up of critical code that didn't get executed in time.

To improve responsiveness, but keep the frequency as low as possible was quite a challenge. I took the existing logic and chucked most of it in the bin...

(Remember, it's keeping the frequency low,*and not UV*that saves power -*read this thread, especially post #2 for more background on this issue)

...what came to replace it was a fairly original hybrid, inspired by ondemand. Ondemand works by jumping to the top frequency when there is any load. This is usually overkill. So, you might have been at 100% CPU utilisation at 384MHz, so ondemand will jump straight to 1512MHz. However, when it gets there, the utilisation is now only 30%, so it will scale down to 486MHz.*

Preservative now works a little like this. Whatever frequency it is currently at, if the utilisation hits 100%, it will scale up. But scaling up to max like ondemand? In the example above, this was the worst kind of overkill. Scaling up to max just to find scaling up one step would have been sufficient. But do we need to scale up one step, or as many as possible? There's no way to know for sure. You have to scale up before you can measure if the extra CPU cycles were enough or not.*

This issue is what Preservative attempts to overcome: if the load is high, it will scale up, but not always to max. Let's label the frequency steps: 384=A 486=B 594=C 702=D 810=E 918=F 1026=G 1134=H 1242=I 1350=J 1458=K 1512=L

Conservative would take 11 calls to the governor to get from A to L, if L was required. Ondemand would go straight there. Ondemand is often overkill, conservative is often underkill. I'd like a compromise. Here's what Preservative would do:

Code:

L <- 4th step selected by preservative K <- 3rd step selected by preservative J <- 2nd step selected by preservative I H G <- 1st step selected by preservative F E D C B A <- sat here until there is load

It splits the difference between whichever frequency it is at and the top frequency, and jumps there. If it is still under high load, it will do it again. So if it is idling, then needs to get to the top, it takes three more calls than ondemand, but seven less than conservative. Not only that, but it has also skipped over a large chunk of the slower steps that conservative would crawl through.

Scaling down also works in a similar way. Preservative will work out what step would be sufficient to manage the load, then jump halfway to that step on the first call. This is because, unlike ondemand, there is no down-threshold. Preservative will scale up when the load exceed the up threshold, but as soon as this is no longer the case, it will start attempting to scale back down to save power. It does not wait for load to reduce to drop below a certain point. Loads fluctuate. If went straight back to A, only to come back back to L, it would have to scale through G J and K again. However, dropping to G then D then B before A means if it does have to scale back up towards L, it doesn't have as far to climb, meaning less calls to the governor, and that the best step can be achieved quicker.*

There has also been an adjustment to the up threshold. When the device is idle, the up threshold will automatically adjust to be more relaxed about scaling up. This means while the device is idle (e.g. when you are just reading some text) it becomes increasingly sensitive to changes in demand. When you touch the screen it will extremely responsive.*

Conversely, when the device is hitting the top frequency, the up threshold will become increasingly strict. So if you are gaming, and putting a lot of load on the CPU, it will aim to be as efficient as possible, and only scale up if it really has to, to ensure that no cycles are wasted at these high power hungry frequencies.

Whenever it goes from hitting L to hitting A, or visa versa, the threshold will reset to default. The sysfs location of this tunable remains at:

/sys/devices/system/cpu/cpufreq/up_threshold

It will accept values of up to 127, higher being more power-saving. The default is 100, but editing the file changes this value. If you want to use a different value on a permanent basis, add the line*

Code:

echo 84 > /sys/devices/system/cpu/cpufreq/up_threshold

to /etc/init.d/00config*

and it will then restore your setting of 84 (or whatever) every time you reboot. Remember it will be overwritten if you flash updates to the kernel, so make a copy of your edited file. However, I believe 100 is a pretty good default."