[Galaxy Note 10.1 Android Development] andip71:
Hi,

there are so many things in pegasusqplus that have been tweaked in, impossible to summarize that in 2 or 3 bullet points.

Personally I do not use the governor as I am a zzmoove-only user. I just put this governor in mainly for S3 CM users requesting it as it seems to behave very nicely there.

Here is the collected info about it from the Perseus thread:

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.

BR

Andi