[Galaxy S III Android Development] andip71:
PegasusqPlus

Hi all,

sorry, I need to update the documentation and help slightly to cover for PegasusQPlus.

But if you do not mind some reading, I copied all the changes AndreiLux did together in one paragraph below.

Enjoy

Andi

==============================================

New PegasusQ logic:

- Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.

- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.

- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.

- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.

- Dynamic Screen Frequency Scaling.

This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):

lcdfreq_enable: Enables or disables the mechanic, disabled by default.

lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.

lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.

- Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.

- Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.

Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.

- Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.

I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.

- Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.

- Default Pegasusq parameters changed:

- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.

- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.

- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.

- Increased the hot-plug frequency conditions for the 4th core.

- Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.

- Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.