Академический Документы
Профессиональный Документы
Культура Документы
1. GOVERNORS .............................................................................................................................................. 2
6) Lulzactive: ............................................................................................................................................. 4
9) SmartassV2: .......................................................................................................................................... 5
19) Performance: ...................................................................................................................................... 7
2. SAMPLE GOVERNOR TWEAKS ................................................................................................................. 10
III) PARAMETERS & TWEAKS: .................................................................................................................. 10
2.LULZACTIVE .......................................................................................................................................... 12
3.SMARTASSV2........................................................................................................................................ 13
4.CONSERVATIVE .................................................................................................................................... 14
5.INTERACTIVE ........................................................................................................................................ 15
IV) GUIDE TO INIT.D SCRIPTS .................................................................................................................. 16
3. MODULES ................................................................................................................................................ 19
1) bthid.ko* - BlueTooth Human Interface Device ................................................................................. 19
3) fuse.ko* - File System in Userspace .................................................................................................... 20
9) hfs.ko - Hierarchical File System ......................................................................................................... 21
15) vibrator.ko* - Vibrate Sensation on Touchsense .............................................................................. 22
4. I/O SCHEDULERS ..................................................................................................................................... 23
2) Deadline .............................................................................................................................................. 24
3) CFQ...................................................................................................................................................... 24
4) BFQ...................................................................................................................................................... 25
5) SIO ....................................................................................................................................................... 25
6) V(R) ..................................................................................................................................................... 26
7) Anticipatory ........................................................................................................................................ 26
5. DUAL CORE CPU Q&A and TWEAKS ........................................................................................................ 28
SIYAH SPECIFIC TWEAKS (2.6 gingerbread versions) .................................................................................. 35
1) CPU Frequency & Voltages ................................................................................................................. 35
2) Scaling Governor & Smooth Scaling Parameters ................................................................................ 35
3) GPU Clock, Voltages, Thresholds & Staycounts .................................................................................. 36
4) Hot Plug Thresholds, Sampling Interval & Frequency ........................................................................ 36
5) Deepsleep Levels ................................................................................................................................ 37
6) I/O Schedulers..................................................................................................................................... 37
Q1. "OK i have flashed this xyz kernel. What're all these governors? How do i know which
one is the best for me? How do i tweak them to bias their characters towards Batterylife/Performance/Balance between the Two".
Q2. "What's the fuzz about these modules that comes with the kernel. How do i use them. Are
they any good. Is it OK to neglect them?"
Q3. "What roles does an i/o scheduler play? How to choose a reliable i/o scheduler?"
Q4. "Can i have more control on CPU? More info and tweaks on dual core CPU, bus
frequency, etc?"
Q5. "Better understanding on impact of different values for basic/advanced parameters in the
Kernel Config App, so that i can tweak the settings according to my taste?"
Hope this thread could give you answers for all these questions. We're covering governors, modules,
i/o schedulers that comes with Siyah kernel, plus more. That should cover almost all the popular
governors/modules/io schedulers! Many people seem to get lost in Kernel dev threads without
getting answers about governors and such.
The info in this thread holds good for non-siyah kernel users too. You should find here, info on most
of the governors/modules/io schedulers in your kernel if not all.
Thanks To
1) Gokhanmoral for his mighty sweet Siyah Kernel which inspired me to write this thread.
2) Moderators for squeezing in extra posts when i ran out of space to fit everything in only 3
reserved posts.
3) Users/Readers for your warm comments.
POST 1: KERNEL GOVERNORS
POST 2: GOVERNOR TWEAKS
POST 3: LOADABLE KERNEL MODULES
POST 4: I/O SCHEDULERS
POST 5: DUAL CORE CPU Q&A AND TWEAKS
POST 6: CONFIGURE KERNEL AIO APP - GINGERBREAD
POST 7: CONFIGURE KERNEL AIO APP - ICS
1. GOVERNORS
I) MANUAL:
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to
max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the
system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the
end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance
right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases
the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us
consider this a reliable governor, it falls short on battery saving and performance on default settings.
One potential reason for ondemand governor being not very power efficient is that the governor
decide the next target frequency by instant requirement during sampling interval. The instant
requirement can response quickly to workload change, but it does not usually reflect workload real
CPU usage requirement in a small longer time and it possibly causes frequently change between
highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery
friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though
ondemand is the default governor in many kernel and is considered safe/stable, the support for
ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very
low latency frequency transitions. I have read somewhere that the performance of
ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most
of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) 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.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for
latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it
determines how to scale up when CPU comes out of idle. The governor has the following
advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in
a workqueue context, but interactive governor does this in a timer context, which gives more
consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the
remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up
work to occur after your performance starved tasks have completed. Interactive It's an intelligent
Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms,
leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the
interactive governor will check whether to scale the CPU frequency up soon after coming out of idle.
When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy
between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp
to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) 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.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in
Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from
Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and
b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor
with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes
out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up
(like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates
the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug
logic runs as a separate thread with the governor so that external hotplugging logic is not required to
control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a
multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims
to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize
battery life without comprising performance. Still, not as battery friendly as smartassV2 since screenon minimum frequency is greater than frequencies used during screen-off. Smartass would jump up
to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The
governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less
aggressive after. It uses different ideal frequencies for screen on and screen off, namely
awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit
sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for
GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike
Smartass). So the entire frequency range is available for the governor to use during screen-on and
screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on
ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon
(Having different governors for sleep and awake). The original intellidemand behaves differently
according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc)
intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand
limits max frequency to a step depending on frequencies available in your device/kernel for saving
battery. This is called browsing mode. We can see some 'traces' of interactive governor here.
Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes
CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max
frequency. (This parameter is tunable only in conservative, among the popular governors
)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when
GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver
performance for gaming and such. Intellidemand does not jump to highest frequency when screen is
off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state
to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to
eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls
more often than ondemand, but changes frequency only after completing min_time_state on a step
overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will
cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.
Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often.
Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a
requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through
each higher frequency step from current. Some users report that video playback using lagfree
stutters a little.
13) 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU
is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
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.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend
profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as
compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if
scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling
decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive,
InteractiveX, Lulzactive, Luzactiveq, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
__________________________________________________
__________________________________________________ ____________
Q. "Well i have set my favorite governor as screen-on governor and another one as screen-off
governor. Why the hell is the phone not waking up after deep sleep. I need to force-restart the
phone by pressing power button for about 10 secs. Is it a sleep-of-death?"
A. Yes it is. Do not use two governors as screen-on & screen-off govs, if they both have an upper
frequency limit for screen-off state.
Didn't get it? Examples for Wrong combinations: (screen-on:screen-off):ondemandX:smartassV2
Examples for right combinations:ondemand:smartassV2, lulzactive:smartassV2
Q. "I can feel slight lags here and there with a governor. For ex: while scrolling through app
drawer/vertically scrolling browser, etc. I really love this governor and don't tell me to use
another governor. Can i diminish this lag?"
A. Hmm well, you can. Basically what we have to do is make the governor "poll" less often to scaledown cpu. Increase down-sampling-time of your governor (whichever parameter that corresponds
to), so that the cpu will stay longer on a frequency before scaling down. This should eliminate the
lag.
Q. "Even though i don't have too much uv/oc, once in a while; may be once in two weeks, i
experience a freeze/lock/reboot. I'm using governor X. How do i solve this?"
A. Well, a random reboot/freeze once in a while signifies that we're android/galaxy SII enthusiast. If
everything go smooth as silk, what's the fun? We could use stock rom/kernel/governor and be
happy. A rare reboot or freeze is nothing to worry about. Just restart the phone.
Q. "OK. I want to tweak these governors according to my usage pattern, because i'm not
happy with the default behavior of these governors".
A. You can tweak the governors using an init.d script to echo suitable values into:
/sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak
Example:
echo "20000" /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
Q. "I'm going to set scaling min freq as 100 mhz because my kernel supports it. Hope there's
nothing wrong in doing that."
A. Wait! You may want to stay away from using 100mhz during screen-off or screen-on states for
three reasons 1) It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz
accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online. 2) 200 mhz
can finish same task faster compared 100 mhz and thus hit deep idle soon. 3) 200 mhz is the 'sweet
spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy
to run (Ex: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
Q. "I want to know is there's anything more i can do to improve battery life. I have already
tweaked my governor settings but..."
A. Take my word. Best way is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of
the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock
1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the
difference.
Q. "How to make my device more snappier. I don't care much about batt....err...I do care about
battery life, but only in terms of avoiding unwanted power consumption. Device should
instantly dance to my tunes."
A. Scale 500 to 1200 during screen-on and 200-500 during screen-off. Use performance tweaked
conservative/ondemand(x). No excess power consumption because 1400 and 1600 is out the
league. Response will be sweet. And don't worry, minimum of 500 during screen-on will not drain too
much battery like you think!
1.ONDEMAND
[ PARAMETERS ]
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make
decisions on what to do about the frequency. Higher values means CPU polls less often. For lower
frequencies, this could be considered an advantage since it might not jump to next frequency very
often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will
scale CPU up. Higher value means less responsiveness and lower values corresponds to more
responsiveness at the cost of battery.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower
frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better
alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - In the simplest form, sampling_down_factor determines how often
CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower
frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior
(for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1
causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is
at its highest clock frequency (which is scaling_max_freq) due to high load. This improves
performance by reducing the overhead of load evaluation and helping the CPU stay at its highest
clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has
no effect on behavior at lower frequencies/lower CPU loads.
10
ii) For performance:To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way,
governor polls more often and scales up quite often.
Code:
echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "50" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step
11
2.LULZACTIVE
1. Initial Version:[ PARAMETERS ]
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
[ SAMPLE TWEAKS ]
Unfortunately, the initial version of lulzactive doesn't give user much control on it's behavior. We can
only control how often cpu should scale up and scale down. Use higher down_sampling_time if you
experience lag while scrolling through browser, app drawer, etc. Better keep the default up_sampling
time (24000) unchanged. And make down_sampling proportional to up_sampling. Like
2x24000=48,000 or 3x24000=72000.
2. Second Version:[ PARAMETERS ]
i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The
frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >=
inc_cpu_load: cpu scaled up
ii) pump_up_step - No of scale up steps when load >= inc_cpu_load
iii) pump_down_step - No of scale down steps when load < inc_cpu_load
iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If
available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5
then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.
v) up_sample_time - same as initial version. (Allowed values 10,000 to 50,000)
vi) down_sample_time - same as older version. (Allowed values 10,000 to 100,000)
[ SAMPLE TWEAKS ]
i) For battery:Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive gradually scale up CPU and rapidly scale down on low load.
ii) For performance:Code:
echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
12
This tweak cause lulzactive scale up CPU rapidly, polling often and scale down gradually.
iii) For balanced-performance:Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive to poll more often and scale up 4 steps above current frequency, but
only at 90% load. CPU is scaled down normally.
note: If you're lazy to use a script, use lulzactive app from market to tweak the
governor. https://market.android.com/details?i...rak.lulzactive
3.SMARTASSV2
[ PARAMETERS ]
i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from
sleep). Thereafter, scaling up is less aggressive.
ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned
off. Thereafter, scaling down is less aggressive.
iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up.
(Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq
when below it)
iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp
down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to
sleep_ideal_freq when above it)
v) max_cpu_load - Same as up_threshold in other governors.
vi) min_cpu_load - Same as down_threshold in other governors.
vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero
disables and will calculate ramp down according to load heuristic. When above the ideal frequency
we always ramp down to the ideal freq.
viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and
causes to always jump straight to max frequency. When below the ideal frequency we always ramp
up to the ideal freq.
ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When
sleep_ideal_freq=0 this will have no effect.
[ SAMPLE TWEAKS ]
i) For battery:-
13
Code:
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
4.CONSERVATIVE
[ PARAMETERS ]
i) down_threshold, ii) up_threshold, iii) sampling_down_factor, iv) sampling_rate - Refer
above governors.
v) freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative
governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
[ SAMPLE TWEAKS ]
i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
14
ii) For performance:- [Isn't it ironical that we are tuning Conservative to achieve blazing
performance!]
Code:
echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
5.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max
freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to UpThreshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp
down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:- [Interactive and battery?!! I'm capping the highspeed_freq in the hope of saving
battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
ii) For performance:- [Assuming your scaling_max_freq is equal to or above 1400 mhz)
Code:
echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
15
GUIDE:
16
17
To Do:
1) Sample SmartassV2 gov tweaks - DONE
2) Sample Interactive gov tweaks - DONE
3) Technical explanation on working of popular governors by the aid of parameters. - Half done,
scattered along Posts
4) More questions in Question Time section - IN PROGRESS
18
3. MODULES
A loadable kernel module is an object that contains some code to extend your kernel. Modules
serves various type of purposes like support for new hardwares, filesystems, and system calls. It is
probable that once a new module is inserted, it might cause minor fragmentation in kernel resulting
in a minor performance penalty. Mostly, not noticeable.
We might ask "ok, if kernel modules are so amazing, why not add them all into the kernel code
instead of asking us to load them". Well, the advantage to LKMs is that you can minimize the
memory footprint for a kernel, loading only those elements that are needed.
You can find all the modules in /lib/modules. (With extension .ko = Kernel Object).
To avail a module, you need to install/insert it by:
Code:
insmod /lib/modules/module-name.ko
Put the line in an init.d script to load the module(s) on every boot.
To view the list of modules that are loaded by default, use:
Code:
lsmod
19
20
21
Q&A
Q. "I can not find a module that i need to use with the current release of my kernel. Can i use
the module downloaded from internet?"
A. Module should be binary compatible with the kernel version. So even if the module was one that
came with an older version of the kernel, it's probable that the compatibility is lost.
Q. "I feel there could be some advantage if i remove modules which is no use for me, but
they're loaded by kernel during boot-up. What can i do?"
A. Put "rmmod name-of-module" in one of your init.d script, so that it's uninstalled on every boot-up.
After booting if you need to use the module, you can insmod it. Ex: rmmod Si4709_driver.ko. (If you
don't use FM radio)
22
4. I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?"
A.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
1) 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:
Disadvantages:
23
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin
policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming
requests.
Advantages:
Disadvantages:
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to
distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue
contains synchronous requests from processes. Time slice allocated for each queue depends on the
priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and
some small backward seeks in the hope of improving responsiveness.
Advantages:
Disadvantages:
24
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process
until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget
assigned to a process varies over time as a function of it's behavior.
Advantages:
Disadvantages:
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests.
No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No
reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
25
6) 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:
I/O Schedulers
Disadvantages:
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read
operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Disadvantages:
26
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used
is a flash device.
Q. "How do i change I/O schedulers?"
Voltage Control or No Frills from market.
Or init.d script:
echo "scheduler-name" > /sys/block/mmcblk0/queue/scheduler
27
28
29
Q. "OK, I'm using hot plug mode, still i want to control how often the second core kicks in. To
make it more aggressive/more mild depending on my usage."
A. You can set UP & LOW thresholds for second core in Screen-On and Screen-Off states.
Examples:
echo "70" > /sys/module/pm_hotplug/parameters/loadh
echo "25" > /sys/module/pm_hotplug/parameters/loadl
echo "90" > /sys/module/pm_hotplug/parameters/loadh_scroff
echo "35" > /sys/module/pm_hotplug/parameters/loadl_scroff
As you can see, when load > 70% second core becomes active and when load drops below 25%,
second core is turned off.
During screen off, these values are 90 & 35 respectively. This helps in reducing unwanted kick-ins of
second during screen-off state when music is playing, downloading, etc.
Q. "Like governors, is there a sampling rate/interval also at which the load on CPU is checked
for crossing thresholds to turn second core ON?"
A. Yes there is. But it is set at kernel level in most kernels and can not be controlled at user level.
Like you guessed, higher sampling rate could cause core 2 to kick in less often and thus save a little
battery. In Siyah kernel though, these thresholds are configurable.
Q. "Advantages/Disadvantages of switching to Single Core/Dual Core modes?
A. Using only single core can save some battery, but can have some adverse effects too if there are
some heavy tasks that require both cores too often: 3d games, full hd videos, etc. So use it wisely.
Using dual core mode can reduce latency by a tiny bit on high loads, as compared to hot plugging.
But hot plugging is intelligent enough to turn second core ON really fast when load demands it. Only
first core (cpu0) can enter deep-idle (LPA), so using dual core mode in an idle system cause
unwanted excess-power consumption.
Recommendation: Use Hot Plugging and tune thresholds (like mentioned above) for a better
experience.
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
30
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.
31
32
MISC Q&A
Q. "What is top-off current?"
A. Charge cycle for the device's battery actually consist of two stage.
First stage consist of supplying a constant current until battery reaches it's constant/peak voltage,
something between 4.1 and 4.2 v.
Upon reaching this peak voltage, a constant voltage is applied until the charge current goes below
top-off current. This is the second stage. Stock top-off current is 200ma. From Siyah 2.6.9, it is set to
100ma just so that a little more juice goes into battery since a lower top-off current means longer the
constant voltage is applied in the second phase of charging.
If you love your battery, do not charge to 'real' 100% too often. Perform the 'trickle' charge only once
every 20 days or so.
Q. "My battery drains fast sometimes immediately after a kernel flash. It's like this: i reboot
the device with 40 percent battery left and when it returns, i have only 20 percent left.
Anything i can do?"
A. Your battery is not actually draining fast. But the fuel gauge is showing funny values which is not
the real percentage left. On high-loads, like immediately after you reboot cause the fuel gauge to
report low percentages. What you can do is to reset the fuel gauge.
[Courtesy Entropy512. The code is for i9100. Location of reset-file may be different in other variants
of GS2]
Give it a few hours after you reset the gauge. It may still show you funny values for those period,
then the battery percentage should be fine.
Code:
echo "1" > /sys/devices/platform/i2c-gpio.9/i2c-9/90036/power_supply/fuelgauge/fg_reset_soc
Q. "So CPU/GPU or GPS chip, which is the biggest power drainer in GS2?"
A. It is the bright amoled display! Display uses roughly 370mW average and 960mW with 100%
brightness full white screen. Avoid bright wallpapers, reduce brightness.
33
Q. "What're the approximate power consumptions by the device peripherals & activities?"
A.
Q. "Sometimes the device says 'low battery' and switches itself off. But when i turn it on,
there's 30% left. Why?"
A. Some heavy load conditions such as quickly reaching 1600mhz on full load, etc will cause the
battery voltage to time below 3.3V and this is wrongly interpreted by the battery as empty.
Q. "What is 500 mhz core voltage bug?"
It's not a bug. It's a safety feature. What is it: When frequency is raised to 500 from a
A.
frequency below it, core voltage used for 500mhz is the core voltage of 800mhz. When frequency is
dropped to 500 from a frequency above it, core voltage used is it's own voltage. So climb to 500
uses 800's volt and fall to 500 uses it's own volt. If you're UVing do it properly for 500 and 800. Now
you know why.
34
35
36
intervals are jiffies. Since frequency of GS2 system timer = 200hz, divide jiffy value by 200 to convert
into seconds.
#Set frequency below which second core will not be turned on, regardless of thresholds.
echo "500000" > /sys/module/pm_hotplug/parameters/freq_cpu1on
If CPU frequency <= 500 mhz, then second will not be turned on.
5) Deepsleep Levels
#Set deep sleep frequency & bus speed (L4=800 mhz and 0=400mhz bus speed)
echo "4" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel
6) I/O Schedulers
#Set i/o scheduler
echo "sio" > /sys/block/mmcblk0/queue/scheduler
7) Bus Frequencies
#Set bus frequencies for highest-to-lowest CPU frequencies and enable static bus frequency scaling
echo "0 0 0 1 1 2 2 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo "enabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
Bus speeds: 0: 400 mhz | 1: 266 mhz | 2: 133 mhz
37
We will have lowest brightness or zero gamma for brightness level read from sensor < 30. Above
that, it is linearly mapped to [min_gamma:max_gamma] which is [1:24] here.
To increase the minimum brightness, decrease the min_bl.
Possible values for min_bl = 0 to 255 | min_gamma = 0 to 24 | max_gamma = 0 to 24
38
SIYAH KERNEL
Thread | App - ExTweaks
TAB 1 - CPU: Take control on CPU hotplugging, throttling, power saving states, etc
1) Hot-Plug Mode: You have a dual-core device. Forcing single core mode is foolishness. You have
room for performance. Forcing dual core mode is also foolishness. Unwanted excess power
consumption even when CPU is 'idling' is the 'minor-reason' and blocking deep idle states is the
'major-reason'. (Only first core can hit deep idle states in Exynos 4210. Never forget this!) It takes
only a few micro seconds to activate/deactivate a core. So use Hotplugging.
2) loadl, loadh: Do not wait for core 1 to be over-loaded to activate second core.
Sample Values: loadl 25, loadh 75 for less aggressiveness or 25 50 for more aggressiveness.
3) loadl_scroff, loadh_scroff: Bluetooth transfers, wifi/3g downloads, music play. Tasks that can
be run during screen-off state are very few. It is recommended to set threshold to 100% so that
second core doesn't kick-in during screen-off state. This will help first core to hit deep idle state soon
after tasks are finished.
Sample Values: loadl_scroff 50, loadh_scroff 100. Value of loadl_scroff is insignificant since Core 2
will not turn on.
4) rate, rate_cpuon, rate_scroff: Compared to governor sampling interval (in the range of micro
seconds), these are normally very high values (terms of seconds or hundreds of milli seconds). Unit
is jiffy. One jiffy is the time taken by one tick of the system timer. Frequency of sgs2 timer is 200hz.
So the value divided by 200 gives the equivalent seconds. In a research it was found that having two
cores online consumes almost same power as having a single core online.
39
Sample Values: rate 100 rate_cpuon 400 rate_scroff 1000. If you want to delay enabling second
core, use 200 400 1000.
Why such a high value for rate_scroff? Because loadh_scroff was set to 100%, core 2 won't kick-in
when screen is off. So the value of rate_scroff doesn't matter. We're simply delaying the next
sampling.
5) freq_cpu1on: CPU runs efficiently if only first core is used until about 800 mhz and both the
cores are used for the higher frequencies (if the load demands).
Sample Value: 800000 (so that second core kicks-in only from frequency>=800 mhz). Or 300000
(so that core2 could be online from 500mhz onwards)
6) Idle Mode, Sched_mc: Unlike 8 idle states supported by OMAP4 of Nexus, GS2 Exynos
supports only 3 idle state: IDLE, AFTR, LPA. Also, load balancing using sched_mc makes no sense
on an already hotplug-enabled device.
Sample Values: Idle Mode 3 (AFTR+LPA), sched_mc 0
7) smooth_target, smooth_offset, smooth_step: If you feel there's a need for 1) throttling CPU 2)
Control governor's urge to jump to maximum frequency too often, then use sensible valid non-zero
values. Otherwise, leave it all zero. NOTE: Smooth scaling is enabled only for ondemand and
conservative governors.
Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2 for the sake of power saving and
precaution. If you prefer not to interfere with governor's decision use 0 0 0.
TAB 2 - GPU: Take control on GPU domain. You decide how many FPS you want!
1) GPU Frequency Steps: There are plenty of frequencies supported by the MALI400. Valid
frequencies are 400/(x*0.5) where 2 <= x <= 20. 400 267 200 160 133 114 100 89 80 73 67 62 57
53 50 47 44 42 40 are valid frequencies. I would recommend using energetically efficient GPU freqs.
Sample Values: 160 200 267. If you want more frames, use 200 267 400.
2) GPU Voltages: GPU Undervolting (if not taken care of) has some worse side effects compared to
CPU UV. Your game will crash, your navigation app will crash. I'd recommend to use stock voltages.
Or just a -50mV UV for each step.
3) GPU UP and DOWN Thresholds: We do not want GPU to immediately scale up after scaling
down to a frequency. This implies the thresholds causes overlapping of load-evaluations. Use upthresholds of the range 80-90. To calculate down-thresholds in such a way that overlapping is
prevented, for a set of two freqs, find out what percentage of higher frequency is lower frequency,
and reduce 5-10 % from the resultant value.
(If you like the 'good old' two frequency step, set Threshold-2-UP to 100 so that only First two Steps
are used and third step will never be active)
Sample Values: 85 70 85 65 (Assuming GPU freqs are 160 200 267). OR 85 65 85 55 (If GPU freqs
are 200 267 400).
40
4) GPU Stay Counts: No of cycles to stay at each GPU step. It is recommended to leave it as
default 1 1 1.
Sample Values: 1 1 1
TAB 3 - SCREEN: Take control on touch response and brightness levels.
1) Touch Move Sensitivity: Supported values are between 0 and 20. Lower value: more
responsive. Set it too low, swipes will be registered as clicks. Set it too high...yeah do not set it high.
Sample Value: 7
2) min_bl,min_gamma, max_gamma: If you don't want lowest brightness to be very low, use 30 1
24.
Sample Values: 30 1 24 (for stock experience) OR 50 0 20 (for low lowest brightness level and low
highest brightness levels)
TAB 4 - MISC: Governor, Scheduler, etc
1) Backup EFS: Backup your precious EFS partition to use in the future to recover a lost IMEI.
2) Android Logger: Enable/Disable Logging. Leave it enabled.
3) Default Ondemand Suspend Frequency: Max frequency to be used by ondemand governor
during suspend state (screen-off). Leave it as 500000.
4) Default CPU Governor: Use whichever you like. New ondemand is good enough.
5) Default I/O Scheduler: Use whichever you like. I use sio/bfq.
6) Charge Current: Since it was proved that i9100 Li-ion battery charge current can only be either of
450mA and 650mA, leave it at AC: 650, MISC: 450, USB:450 or AC:650 MISC: 650 USB:450
7) Reset Fuel Gauge Chip: After a low-battery reboot if the battery shows very low and incorrect
percentages since true battery capacity failed to accurately synchronize with the fuel gauge, press
the button and wait for sometime. An alternative is to charge full->discharge full->charge full.
Last Words: If you use scripts to set bus frequencies, i recommend leaving static bus frequency
disabled. Tasks which involves a lot of GPU rendering really does a lot of Write and Read To and
From memory. Let the system decide what bus frequency should be used.
41
FECALITY KERNEL
Thread | App - ExTweaks
TAB 1 - CPU: See above for config hints/sample values for each parameters under this tab.
1) loadh, loadl:
2) loadl_scroff, loadh_scroff:
3) rate, rate_cpuon, rate_scroff:
4) freq_cpu1on:
5) CPU Idle Mode:
TAB 2 - GPU: See above for config hints/sample values for each parameters under this tab.
1) GPU Frequency Steps:
2) GPU Voltages:
3) GPU UP and DOWN Thresholds:
TAB 3 - MISC: See above for config hints/sample values for each parameters under this tab.
1) Backup EFS:
2) Default CPU Governor:
3) Default I/O Scheduler:
4) File Fsync Disable: If FSYNC is used, and a file is open for writing, all cached data will be written
to disk. This feature helps to minimize data loss under rough conditions, where power failures can
occur. Only advantage to disable per file fsync is increased performance in DB writes, etc. This can
also be achieved using a different i/o scheduler. Disabling Pfsync is dangerous as it can lead to data
corruption. Do not disable Pfsync.
5) Reset Fuel Gauge Chip:
42
N.E.A.K KERNEL
Thread | App - N.E.A.K Configurator
Q. "Even though i could understand everything you stated here about, what exactly does
those sample values/recommended settings do? Will i get 8 hours screen-on and 8000
Antuntu?"
A. We have a Galaxy S2, not Nokia 1100. We should utilize and enjoy the performance of the
phone. The values recommended were intended to give snappiness without compromising too-much
battery life. Our definitions of 'too-much' may be different. But i assure you the difference isn't too
much!
43
SIYAH KERNEL
Thread | App - ExTweaks
44
Sample Value: 800000 (so that second core kicks-in only from frequency>800 mhz).
6) CPU Idle States: Unlike 8 idle states supported by OMAP4 of Nexus, GS2 Exynos supports only
3 idle state: IDLE, AFTR, LPA.
IDLE - Clock is gated but power on CPU core remains (static power consumption still active)
AFTR - Clock is gated, power on CPU core is removed and L2 cache power remains. Static power
consumption mostly eliminated.
LPA - Cache power removed.
AFTR or LPA cannot be entered if second core is active.
Sample Values: Idle Mode 3 (AFTR+LPA), to save battery.
7) Sched_mc: Disable sched_mc. There could be only one situation where load balancing or weirdoverloading of first core can be useful - when we use dual core mode. Sched_mc is valid only when
both cores are online. Since it doesn't go well with hotplugging logic, if someone uses dual-core
mode sched_mc is worth a try to handle task loads on cores.
Sample Values: sched_mc 0
8) smooth_target, smooth_offset, smooth_step: These params helps in 1) Throttling CPU at
higher temperatures 2) Control Ondemand based governors' urge to jump to maximum frequency
too often by jumping the CPU to an intermediate frequency first. If we're not interested in either of
them, leave it as 0 0 0. NOTE: Smooth scaling is enabled only for Ondemand and Conservative
governors.
Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2
TAB 2 - GPU: GPU behavior. This matters more than CPU UV w.r.t Screen-On power savings!
1) GPU Frequency Steps: There are plenty of frequencies supported by the MALI400. Valid
frequencies are 400/(x*0.5) where 2 <= x <= 20. 400 267 200 160 133 114 100 89 80 73 67 62 57
53 50 47 44 42 40 are valid frequencies. I would recommend using energetically efficient GPU freqs.
Sample Values: 160 200 267. If you want more frames, use 200 267 400.
2) GPU Voltages: GPU Undervolting (if not taken care of) has some worse side effects compared to
CPU UV. Your game will crash, your navigation app will crash. I'd recommend to use stock voltages.
Or just a -50mV UV for each step.
45
3) GPU UP and DOWN Thresholds: The four thresholds are threshold to switch to second step,
switch back to first step, switch to third step, switch back to second step. We do not want GPU to
immediately scale up after scaling down to a frequency. This implies the thresholds are overlapping
load-evaluations. Use up-thresholds of the range 80-90. To calculate down-thresholds in such a way
that overlapping is prevented, for a set of two freqs, find out what percentage of higher frequency is
lower frequency, and reduce 5-10 % from the resultant value.
(If you like the 'good old' two frequency step, set Threshold-2-UP to 100 so that only First two steps
are used and third step will never be active)
Sample Values: 85 70 85 65 (Assuming GPU freqs are 160 200 267). OR 85 65 85 55 (If GPU freqs
are 200 267 400).
4) GPU Stay Counts: No of cycles to stay at each GPU step. It is recommended to leave it as
default 1 1 1.
Sample Values: 1 1 1
TAB 3 - SCREEN: Touch sensitivity, Brightness curve
1) Touch Move Sensitivity: Supported values are between 0 and 20. Lower value is more
responsive. But setting it too low will cause swipes to be registered as clicks.
Sample Value: 7 pixel
2) min_bl,min_gamma, max_gamma: If you don't want lowest brightness to be very low, use 30 1
24.
Sample Values: 30 1 20 (for stock experience)
OR 50 0 20 (for low lowest brightness level and low highest brightness levels)
TAB 4 - MISC: Governor, Scheduler, Miscellaneous tweaks
1) Backup EFS: Backup your precious EFS partition to use in the future to recover a lost IMEI.
2) Android Logger: Enable/Disable Logging. Leave it enabled.
3) Default Ondemand Suspend Freq: Max frequency that will be used during screen-off state if
Ondemand is the active governor. 500000 (500 mhz) is the most sensible value.
4) Default CPU Governor: Use whichever you like. Ondemand is good enough.
5) Default I/O Scheduler: Use whichever you like. I use sio/bfq.
6) Charge Current: Since it was proved that i9100 Li-ion battery charge current can only be either of
450mA and 650mA, leave it at AC:650, MISC:450,USB:450 OR AC:650 MISC:650 USB:450
46
7) Reset Fuel Gauge Chip: After a low-battery reboot if the battery shows very low and incorrect
percentages since true battery capacity failed to accurately synchronize with the fuel gauge, press
the button and wait for sometime. An alternative is to charge full->discharge full->charge full.
8) Remove Root: Some apps detects root and refuse to work if found. In such cases, or if some
apps are freezing in a while, remove root and re-install root. Pressing the button will remove
Superuser.apk and SU binary.
9) Install Root: Tries to install root after a removal. Copies Superuser.apk and SU binary. If this
fails, check 'Auto-Install Root' and reboot.
47