[Nexus 7 Original Development] Ezekeel:
I have released GLaDOS V1.4 with some significant improvements.

First I have switched the memory allocator back to SLAB which is also used on the stock kernel. SLQB was causing some sort of memory leakage which gradually reduced the memory available for the system and resulted in a system crash and soft reboot.

Second I have removed that terribad autohotplug driver Nvidia came up with and replaced it with my own conceptually simple CPU hotplug driver which eliminated all of the strange lags and wakeup delays experienced with the previous versions and also improved the battery life since it efficiently cuts down the overhead of unnecessary CPU hotplugging due to load jitter and temporary load spikes.

The hotplug driver is highly customizable and an interface to its parameters has been included in the latest version of GLaDOS Control. The defaults should be working fine, but I did not look into tweaking yet so there might be some improvements to again. So if you decide to play around with these values and find some combination which is working even better please feel free to share your findings - if the general consensus it that they are better than the current defaults I will adjust the defaults.

The design of the hotplug driver is based on two principles:

* Running a SMP processor with a single core on a frequency f needs more energy than running n cores on a frequency f/n. The reason is that the dynamic energy consumption scales linearly with the frequency and quadratically with the voltage and that higher frequencies need a higher voltage.

* For modern SoC in smartphones the static energy consumption makes up more than two-third of the entire energy consumption of the processor and the only way to get rid of it are the low power CPU states which switch off large parts of the CPU. The problem is that most CPU designs require that all core switch to this low power state simultaneously, so all cores have to be idle at the same time. With an increasing number of online core purely due to statistical reasons this requirement can be met less often. This means that reducing the number of online cores can help to improve the average time spend in the low power state which in turn reduces the energy consumption.

So while the first principle suggests that we run with as many online cores as possible, unfortunately the second one demands exactly the opposite and that we turn off as many cores as possible. So one needs to balance out these two factors in some reasonable way.

The simple approach I took was to assume that the CPU will only be able to use the low power state effectively when the total load summed up over all online cores generally is low. In detail, low enough that one single core can sustain that load with a CPU usage of around 50%. In this case all but one core are switched off to maximize the use of the low power state. When the load exceeds that threshold it is assumed that the low power state will not able to be used efficiently anyway so the second principle does not apply in this case and we follow the first principle and run with as many cores as possible.

This simple approach yields a simple design for the hotplug driver which switches between single-core and multi-core (all cores online) mode without intermediary steps, i.e. more than one but less than possible cores online. To avoid rapid mode switching due to temporary load spikes and load jitter two thresholds are used for single->multi and multi->single mode switches with a gap between them. Also the hotplug driver can be configured to allow a certain number of load spikes during single-core mode above the threshold before switching to multi-core mode.

I ran some test and observed the behavior of the driver in practice and the responsiveness seems to be excellent while on the other hand the number of unnecessary CPU hotplugging was cut down to almost zero.