[Galaxy S II General] Stifler69:
Information on misc tweaks, plus my favorite governors and schedulers i recommend

Abit more info regarding what are the misc options in the NEAK configurator application. (Many thanks to Droidphile for all the information)

Q. "What are these modes: IDLE, LPA and AFTR?"

A. Between screen off and deep sleep states, there are some idle modes supported by cpuidle driver. They are IDLE aka Normal Idle, LPA aka Deep Idle and AFTR aka ARM Off Top Running. Race to idle by CPU is implemented for power management.

In IDLE state, CPU is not clocked anymore, but no hardware is powered down.

In deep idle (LPA),a state after IDLE, again, the cpu is not clocked anymore like we guessed but some parts of hardware are powered down. Deep idle brings in real power savings and there is no need of putting a hard limit to frequency during screen-off; using a screen-off profile. (Good practice is to use a governor with built in screen off profile, than using an user-configured screen-off profile by putting a hard limit on frequency). Deep idle is not used when device is entering deep sleep and also when device is woken from suspend/deep sleep. While entering/exiting DEEP IDLE, CPU is set statically to SLEEP_FREQ and is not clocked below or above until it exits this state.

AFTR is a patch to support Top=Off mode for deep idle. Level 2 cache keeps it data during this mode.

We can have IDLE or AFTR modes with LPA enabled or disabled. (Obviously it is not possible to have IDLE and AFTR together)

Values:

0: IDLE

1: AFTR

2: IDLE+LPA

3: AFTR+LPA

Q. "What idle modes are recommended for power saving? How do i change it"?

A. Recommended for power saving is to enable AFTR and LPA, ie value 3

Example:

echo "3" > /sys/module/cpuidle/parameters/enable_mask

Q. "What is sched_mc?"

A. Linaro team invented sched_mc or Schedule Multi Core to make process scheduling multi-core aware. ie, utilize both cores wisely to save power and balance performance. Even though sched_mc is sort of an alternative to cpu hot plugging, we can use sched_mc with the default hot plug mode.

Possible Values:

0 : No power saving load balance, default in our exynos4210 Soc.

1 : Fill one thread/core/package first for long running threads. In our single-CPU dual-core device, multithreading does not come into picture, so load balancing is almost redundant to hotplugging.

2 : Also bias task wake-ups to semi-idle CPU package for power savings. (Bias new tasks to cpu1 if cpu0 is mostly filled with running tasks). This is 'overloading' CPU0 first.

Q. "What value is recommended for sched_mc?"

A. 1) If you find advantages to sched_mc, use sched_mc=1 for a possible battery saving. Anyhow since load-balancing is reduntant on hotplugging, it may not have any advantage on exynos chip.

2) For performance use 2. But do remember that loading CPU0 and leaving CPU1 can not do justice to hitting deep idle states sooner since second core can not enter deep idle. So extra performance or no performance, value 2 will drain some more battery, in the context of delayed didle.

3) To do justice to hotplugging, use value 0.

Example:

echo "0" /sys/devices/system/cpu/sched_mc_power_savings.

Schedulers that i recommend to use. Again massive thanks to Droidphile for the information.

Noop

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Advantages:

Serves I/O requests with least number of cpu cycles. (Battery friendly?)

Best for flash drives since there is no seeking penalty.

Good throughput on db systems.

Disadvantages:

Reduction in number of cpu cycles used is proportional to drop in performance.

V(R)

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

Advantages:

May be best for benchmarking because at the peak of it's 'form' VR performs best.

Disadvantages:

Performance fluctuation results in below-average performance at times.

Least reliable/most unstable.

Governors that i recommend to use. Information again by Droidphile.

Lulzactive:

This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.

Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.

New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.

When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.

Example:

Consider

inc_cpu_load=70

pump_up_step=2

pump_down_step=1

If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.

If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.

Conservative:

A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.

Lionheart:

Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.

Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.

Do not forget to enable the Lionheart tweaks you must have Conservative governor enabled through the configurator application and then select Lionheart tweaks

Links

*N.E.A.K kernel:

http://xdaforums.com/showthread.php?t=1411788

*Droidphile thread regarding more info about governors and schedulers and more tweaks

http://xdaforums.com/showthread.php?t=1369817

*Ext4 Optimization information

http://kernelnewbies.org/Ext4

*N.E.A.K Configurator App.

https://play.google.com/store/apps/details?id=com.neak.NEAK_Configurator

*If you want to try alternative settings from mine and try settings near stock default go to the following thread by Geko95gek and check his great thread out.

http://xdaforums.com/showthread.php?t=1466017