[KERNEL-ICS] GLaDOS by Ezekeel 4.0.3 / 4.0.4 V1.30

• Override factory-set limitations for the MPU greatly increasing the OC potential.

• Added a safety feature to Color Control to prevent the color multipliers to be raised above the stock values.

• Added 1.4GHz MPU frequency slot.
• Added support to Color Control for disabling the safety preventing the color multipliers being raised above the stock values.

• Added 1.6GHz MPU frequency slot.
• Fixed bug in Live OC of the min/max frequency values not being properly adjusted when changing the MPU OC value.

• Fixed Sound Control issue with delayed touch control sounds and other sound glitches.

• Removed previous sound tweak and added Sound Control version 1.

• Added audio tweaks supporting changing the volume boost and enabling/disabling high performance audio.
• Added memcpy/memmove glibc functions improving performance of these memory operation.

• Fixed stability issues when changing the MPU OC value with LiveOC.

V1.4 updated
GLaDOS-V1.4

• Added 'Wheatley' CPUfreq governor and made it default.

Ezekeel's commentary on V1.4

I have release GLaDOS V1.4 including my new CPUfreq governor 'Wheatley' which is the new default governor.

The previous benchmarks of the usage of the C4 state for different activities have shown that for 'light' tasks like browsing the internet, reading (for example emails or eBooks) and the average app the device spends about 40% of the time in C4 with acceptable average residencies of around 11ms. For more demanding tasks like games and video playback the C4 state is still being used however the efficiency is reduced due to the low average residencies of below 5ms (considering that the wakeup latency is 1.3ms).

I have run a few tests and as it turns out, for demanding tasks the efficiency of the C4 state is significantly reduced due to these low residency times (= large number of wakeups) to a point that the good old frequency scaling is indeed more efficient with larger battery savings. So unfortunately, relying on the C4 state alone for power savings for all tasks is not a good option.

However, unfortunately we also cannot simply use one the available standard governors since always try the minimize the frequency without taking account that this behaviour diminishes the efficiency of the C4 state since it hinders a proper race-to-idle. So taking advantage of this knowledge what a good governor should do, is using the maximum frequency whenever the C4 state is properly used with acceptable average residencies and only scale down when the average residencies get too low (or the C4 is not used at all, of course).

Building on the classic 'ondemand' governor I implemented this idea in my new Wheatley governor. The governor has two additional parameters:

target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.

allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.

I have run some benchmarks to make sure that Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly (as seen in the previous benchmarks).

For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.

So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

Wheatley for governor!

Zum Vergrößern anklicken....