[INFO][KERNEL] GLaDOS by Ezekeel | GSM / Verizon / Sprint

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!

zephiK said:

Yeah I appreciate what rootzwiki does for the developers. It definitely favors them, it just hurts the users because they are unaware of these great and talented developer's work that's being exclusive to rootzwiki. Because, lets be honest, rootzwiki is nice to developers, but its not as popular as XDA causing a lack of awareness of releases.

I already feel this because the rom I use gets updated the fastest on rootzwiki. The xda thread of the rom is 1-2 builds behind.

That's just my take on rootzwiki. It definitely makes people go to their site. But I just don't think its right to split the community between the two websites.

Sent from my Galaxy Nexus using xda premium

Click to expand...

Click to collapse

You can be member of XDA and RW at the same time. So I do not see how this is splitting up the community. You can link XDA threads on RW and vice versa. No matter what forum you are currently on, the other always is only one click away. All barriers you might see that split up the community, are in reality only in your mind.

I agree that it can cause a little more effort for the users since they might have to check two forums for updates. But let me be frank here, compared to all the effort I invested in writing this kernel this tiny bit of extra work for the users is hardly anything to complain about. If you have the time to play around with custom kernels and ROMs on your device, you got the time to check a second forum once in a while for updates.

V1.14 released

☞click GLaDOS for Galaxy Nexus (aka Nexus Prime)

Ezekeel's commentary on that

I have released GLaDOS V1.14.

The OMAP4 processor build in the GN come out of production in different qualities and some chips are able to run higher frequencies than others. To account for this the processors are binned in the factory and the information about the quality is fused into a certain chip register. Among other things this information contains the MPU DPLL trim value which (indirectly) limits the maximum MPU frequency which the chip will be able to support.

Overriding this factory-set MPU DPLL trim value removes the hard limit for the maximum MPU frequency. For example, the chip build my GN device is binned for a maximum MPU frequency of 1.2GHz and the maximum frequency I was able to reach with LiveOC was 1.32GHz (there seems to be some leeway). After overriding the trim value I was able to achieve 1.62GHz.



GLaDOS-V1.14

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