Database Users

[Q] SetCPU tweaks for Droid X?

So just curious...anyone played around with the settings for "Advanced" on their DX? Wondering if anyone has found any values that work better and give better performance/battery life then leaving it as-is.
Not new to using SetCPU btw...been using it since I rooted/installed a custom ROM sometime last year.

JagoX said:
So just curious...anyone played around with the settings for "Advanced" on their DX? Wondering if anyone has found any values that work better and give better performance/battery life then leaving it as-is.
Not new to using SetCPU btw...been using it since I rooted/installed a custom ROM sometime last year.
Click to expand...
Click to collapse
I usually lower the sampling rate so that it checks itself more often... I also lower the up threshold to somewhere between 20%-35% so when the cpu load hits that percentage setcpu will tell the cpu to go "balls to the wall"...
"4. Advanced Tab
The Advanced menu allows you to tweak the finer aspects of certain CPU governors. It is only activated when you choose the ondemand or conservative governors.
Sampling Rate – An interval (in microseconds) at which the governor will poll for updates. When this happens, the governor will decide whether to scale the CPU up or down.
Up Threshold – Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU up.
Down Threshold (conservative only) – Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU down.
Ignore Nice Load – If this value is “1,” the system will ignore “Nice” processes when deciding to scale up or down.
Powersave Bias (ondemand only) – Setting this value higher will “bias” the governor toward lower frequencies.
Choose the “Set on Boot” checkbox to apply advanced settings when the phone boots. This option is completely independent of the similar option in the Main tab."
Sources:
http://forum.xda-developers.com/showthread.php?t=505419
http://www.setcpu.com/

If you don't mind me asking what value do you change the sampling rate to? What kind of performance improvement to you see?
What rom you running btw?

[REF][ICS] Kernel Stuffs - How is ICS Kernel Different | updated may-28-2012

Hello again to all the people suffering from Obsessive Kernel Flashing Disorder. After i wrote an essay in this thread and bored the readers to death, here is a new thread as a reference to ICS kernel related stuffs. ICS is not a 100% different. But there are differences. Idea here is to understand "How is 3.0 ICS Kernels different from 2.6.35 GB Kernels". Additions, deletions, modifications?
Index:
Post 1: Understanding all the Kernel Tunables
Post 2: Exclusive Features - Dual Booting and BLN Breathing
Post 3: All New Governor - Pegasusq. Parameter Explanations, Sample Tweaks, How to Tweak
Post 4: Kmemhelper Binary Interface - Enjoy Virtual Kernel Hacking
Post 5: Miscellaneous FAQs on Kernel from Different Angles
To begin with we will understand some of the tunables in ICS kernels, taking Gokhanmoral's Siyah kernel as a reference. (Yes, the info here are also valid for other ICS kernels for SGS2). Universal Configurator Interface app ExTweaks has the following tunables with Siyah kernel.
Note: All the tunables explained below may not be available for your current kernel build. Devs tend to experiment by removing some interfaces and adding them back later.
TAB 1 - CPU: Task Scheduler, Hotplugging, Smooth Scaling, Idle States
1) CFS Tweaks:
CFS is the default task scheduler. A task/CPU scheduler does process scheduling, ie manages how the threads, processes or data flows are given access to system resources. (I/O scheduling is different. I/O scheduler schedules I/O requests) CFS uses a binary search tree instead of run-queue method to maintain a timeline of future task execution. Note: Results of task scheduler tuning are experienced only during multi tasking, not during benchmarks.
a) GENTLE FAIR SLEEPERS
Significance: Android UI Interactivity.
Sleeper Fairness is a concept used by CFS which treat sleeping/waiting tasks as if they were in a run queue. This implies tasks which spend most of the time waiting for an user input and such will get a fair share of CPU when they need it. Disabling Gentle Fair Sleepers could improve UI responsiveness.
Tweaking Via Script:
#disable
echo "NO_GENTLE_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features
#enable
echo "GENTLE_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features
b) ARCH POWER
Significance: ARM Topology Awareness.
Arch Power patch causes arch dependent power functions to be used instead of generic high resolution timer ticks and double ticks.
Tweaking Via Script:
#disable
echo "NO_ARCH_POWER" > /sys/kernel/debug/sched_features
#enable
echo "ARCH_POWER" > /sys/kernel/debug/sched_features
2) Hotplug Mode:
Significance: ON/OFF behavior of CPU cores.
Hotplugging as we know dynamically activates second CPU core ON on load conditions and turns second core OFF on low load conditions. Best practice is to use hotplugging instead of single/dual core modes and tweak settings in such a way that until about 800 mhz, only first core is active. This is energy efficient since voltage increase is steep for frequencies above 800mhz. So static power consumption increases sharply and it's better to have two cores handling tasks from here on. According to a test, having only one core online roughly saves about 55% power compared to two cores online. But it's not worth using single core for all frequencies since the device is capable of more.
Sample Value: CPU Hotplug
Tweaking Via Script:
#HOTPLUG
echo "on" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "on" > /sys/devices/virtual/misc/second_core/second_core_on
#SINGLE CORE:
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "off" > /sys/devices/virtual/misc/second_core/second_core_on
#DUAL CORE:
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "on" > /sys/devices/virtual/misc/second_core/second_core_on
3) load_h0, load_l1:
Significance: Thresholds to ON/OFF second CPU core
Load-High-0 and Load-Low-1 are UP/DOWN thresholds to turn ON and turn OFF second core. When load on first core is greater than loadh0, second core comes online. When average load on both cores is less than loadl1, second core goes offline. Do not overload first core before turning second core on aka do not use high thresholds. See Q&A at the bottom of the post
Sample Values: Less Aggressive: load_h0 50, load_l1 20. More Aggressive: load_ho 30 load_l1 20.
ICS hotplugging logic is different from GB hotplugging. To get the same responsiveness as in gingerbread, use more aggressive(reduced) load_h0 thresholds.
Valid Values: 0 to 100%
Tweaking Via Script:
echo "30" > /sys/module/stand_hotplug/parameters/load_h0
echo "20" > /sys/module/stand_hotplug/parameters/load_l1
4) min_rq, load_rq:
Significance: Enhance hotplugging via CPU Run Queue and Process Priorities
ICS has multiple hotplugging concepts. What's normally used is Standalone Hotplug. We also have the one like GB's (remember loadh, loadh_scroff, loadl, etc). min_rq - Minimum Run Queue and load_rq Load on Run Queue are two parameters to increase multi thread awareness of ICS hotplugging. With these parameters we achieve the goal of turning of second core if fewer task threads are running - even if load is high.
If no of threads running on a Core is less than min_rq and load of that Core is less than load_rq, second core is turned off. Note that the load threshold considered here is for only one core (unlike load_l1 which takes average load on cores to make turning-off-second-core decision).
Example: Let min_rq=2 and load_rq=40%. Suppose both cores are online. Average load on cores has not dropped below load_l1 so it's still not time to turn off second core. But say only one thread is running on second core and load on that core is 30%. Then second core will be turned off.
Sample Values: min_rq 2, load_rq 20%
Valid Values: min_rq: 0, 1 and 2. load_rq: 0 to 100%
Tweaking Via Script:
echo "2" > /sys/module/stand_hotplug/parameters/min_rq
echo "20" > /sys/module/stand_hotplug/parameters/load_rq
5) rate:
Significance: Hotplug Sampling Interval
Every rate jiffies, load is sampled and if found to be more than loadh0, second core is turned ON. One jiffy is the time taken to complete one tick of the system timer. Sgs2 timer frequency is 200hz. So the value divided by 200 gives the equivalent seconds or in other words, one jiffy = 5 milliseconds in GS2 terms.
Sample Values: rate 100.
Valid Values: 50 to 1000 jiffies, in terms of 50s.
Tweaking Via Script:
echo "100" > /sys/module/stand_hotplug/parameters/rate
6) freq_min:
Significance: Cut-off frequency for second core to turn ON
'Threshold' frequency for second core to turn ON during hotplugging. If current frequency <= freq_min, second core will not turn on even if the load has crossed loadh0. CPU runs efficiently if only single core is used until about 800 mhz and both the cores after 800.
Sample Value: freq_min 800000
Valid Values: All the values in freq_table
Tweaking Via Script:
echo "800000" > /sys/module/stand_hotplug/parameters/freq_min
7) CPU Idle States:
Significance: Power saving CPU idle modes that are 'encountered' between screen-off and deep-sleep.
Unlike 8 idle states supported by Nexus OMAP4, GS2 Exynos supports only 3: 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 cores 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.
Valid Values: 0, 1, 2, 3
Tweaking Via Script:
#AFTR+LPA
echo "3" > /sys/module/cpuidle_exynos4/parameters/enable_mask
#IDLE+LPA
echo "2" > /sys/module/cpuidle_exynos4/parameters/enable_mask
#AFTR only
echo "1" > /sys/module/cpuidle_exynos4/parameters/enable_mask
IDLE only
echo "0" > /sys/module/cpuidle_exynos4/parameters/enable_mask
8) Sched_mc:
Significance: Increases multi-core awareness!?
Sched_mc aims to schedule tasks between multiple cores in the CPU. Sched_mc can be a) OFF (value 0), b) load balance (value 2) the cores by keeping the load even between them or c) power-save balance (value 1) by loading first core until it's 100% loaded. Hotplugging does load balancing already by taking care of thresholds, run queues, process priorities, cut-off frequency, etc. So there's no use of sched_mc = 1. Powersave balancing which overloads first core will increase the time to relieve first core (as compared to same task balanced between both the cores). This will cause delay to hit deep-idle states, since only first core can enter AFTR/LPA states.
Disable sched_mc. There could be only one situation where load balancing or weird-overloading of first core can be useful - when we use dual core mode. Sched_mc is valid only when both cores are online. If someone uses dual-core mode sched_mc is worth a try to handle task-loads across cores.
Sample Values: sched_mc 0
Valid Values: 0, 1, 2
Tweaking Via Script:
#disable sched_mc
echo "0" > /sys/devices/system/cpu/sched_mc_power_savings
#enable first core overloading
echo "1" > /sys/devices/system/cpu/sched_mc_power_savings
#load balancing
echo "2" > /sys/devices/system/cpu/sched_mc_power_saving
9) smooth_target, smooth_offset, smooth_step:
Significance: CPU Throttling
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 Pegasuq governors.
Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2
Valid Values: 0, 1, 2, 3, 4 (for all three params)
Tweaking Via Script:
echo "1" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step
10) smooth_level:
Significance: Intermediate Step Before Scaling Max Freq
smooth_level is a standalone parameter to control smooth scaling. When ondemand/pegasusq governors instruct CPU driver to scale CPU up to max frequency, CPU driver first scales CPU to smooth_level then on next sampling to highest frequency. Only goal here is to save some battery.
Sample Values: smooth_level 800mhz
Valid Values: Level number of any frequency between your scaling min frequency and scaling max frequency.
Tweaking Via Script:
#Level 8 in 18step freq table is 800mhz
echo "8" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_level
11) CPU Step Counts:
Significance: Set of Available Frequencies aka 'Tightness of Freq Table'
Some are O.K with Samsung defaults of 5 frequency steps, some users need a 1400 on top, some needs a 1600 too. Some would like to set intermediate frequencies in between. To satisfy everyone, we have configurable CPU Frequency Table to echo custom frequency steps. Possible step counts (selectable from ExTweaks) are
5 - Samsung default: Good old 200-500-800-1000-1200.
6 - Sammy default plus 1400 mhz: 200-500-800-1000-1200-1400
7 - 6 Step plus 1500: 200-500-800-1000-1200-1400-1500
8 - 6 Step plus 100 in the 'bottom' and 1600 on 'top': 100-200-500-800-1000-1200-1400-1600
9 - 8 Step plus 1500: 100-200-500-800-1000-1200-1400-1500-1600
18 - All possible 18 steps.
Note: Any number of steps between 3 and 18 is possible (use script). Only condition is 500,800 and 1000 should be present in the list.
Sample Values: Select any step count you like
Valid Values: 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 700, 600, 500, 400, 300, 200, 100, 50, 25. (In Mhz. Note that you echo to the table as Khz)
Tweaking Via Script:
echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
12) Scaling Min & Max Frequencies:
Significance: Frequency Range to be Used from Frequency Table
Any governor will scale CPU up and down between scaling_min_frequency and scaling_max_frequency. We change value of these two to UC/OC
Sample Values: scaling_min_frequency 200 and scaling_max_frequency 1200
Valid Values: Any frequencies from frequency table. Only condition is scaling_max_freq should be greater than scaling_min_frequency.
Tweaking Via Script:
echo 200 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1200 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
TAB 2 - GPU: GPU behavior. This matters more than CPU UV w.r.t Screen-On power savings!
1) GPU Frequency Steps:
Significance: Configurable GPU Frequency Steps
There are plenty of frequencies supported by the MALI400. Valid frequencies are 800 divided by an integer not greater than 20. I would recommend using energetically efficient GPU freqs. Note that any Nth step can not be less than (N-1)th step.
Sample Values: 160 200 267. If you want more frames, use 200 267 400.
Valid Values: 400 267 200 160 133 114 100 89 80 73 67 62 57 53 50 47 44 42 40
Tweaking Via Script:
echo "160 200 267" > /sys/class/misc/gpu_clock_control/gpu_control
2) GPU Voltages:
Significance: Set enough voltage to support your underclocked or overclocked GPU frequency steps.
GPU Undervolting (if not taken care of) has some worse side effects compared to CPU UV. Your game and navigation app will crash. I'd recommend to use stock voltages. Or just a -50mV UV for each step.
Sample Values: 950 1000 1050
Valid Values: 800mV to 1200 mV at 50mV steps.
Tweaking Via Script:
echo "900000 950000 1000000" > /sys/class/misc/gpu_voltage_control/gpu_control
3) GPU UP and DOWN Thresholds:
Significance: When should GPU scale up and down across GPU frequency steps.
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 scale up immediately 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. Ex: for 160 to 200, 160 is 80% of 200. Reducing 10% gives 70%.
(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 (For GPU steps 160 200 267). OR 85 65 85 55 (For GPU steps 200 267 400).
Valid Values: 0 to 100%
Tweaking Via Script:
echo "85% 70% 85% 65%" > /sys/class/misc/gpu_clock_control/gpu_control
4) GPU Stay Counts:
Significance: Delaying next sampling/stay at a GPU step for longer time.
Staycount is the no of cycles to stay at each GPU step. It is recommended to leave it as default 1 1 1. A check in dvfs part make sure that changing frequencies happens only after staycount expires - regardless of load crossing thresholds.
For example : Staycount of 1 0 2 for 160 200 267 steps implies => i) A transition from 160 to 200 happens only a after a minimum of 1 second even if load on 160 exceeded the threshold before 1 second expired. ii) A transition from 200 to 267 or 160 can happen anytime load crosses threshold. iii) A transition from 200 to 267 happens only a after a minimum of 2 seconds even if load on 160 exceeded the threshold before 2 seconds expired.
Sample Values: 1 1 1
Valid Values: 0, 1, 2, 3, 4, 5 Seconds
Tweaking Via Script:
echo "1 1 1" > /sys/class/misc/gpu_clock_control/gpu_staycount
TAB 3 - SCREEN: Touch sensitivity, Brightness curve
1) Touch Move Sensitivity:
Significance: Improving touch 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
Valid Values: 0 to 20 pixels
Tweaking Via Script:
echo "7" > /sys/devices/platform/s3c2440-i2c.3/i2c-3/3-004a/mov_hysti
#Another touch sensitivity parameter is tsp_threshold which can take the values between 40 and 80 at steps of 10. Lower value is more responsive.
echo "50" > /sys/devices/virtual/sec/sec_touchscreen/tsp_threshold
2) min_bl, min_gamma, max_gamma:
Significance: Brightness Response Curve.
If you don't want lowest brightness to be very low, use 30 1 20 which are stock values. We will have lowest brightness or zero gamma for brightness level read from sensor < min_bl (30 here). Brightness levels above that is linearly mapped to [min_gamma:max_gamma] ( [1:20] here). To decrease minimum brightness level (some users find the lowest brightness level too bright in dark conditions), increase min_bl.
Sample Values: 30 1 20 (for stock experience) OR 50 0 15 (for low lowest brightness level and low highest brightness levels)
Valid Values: min_bl 0 to 150, min_gamma 0 to 20, max_gamma 0 to 20
Tweaking Via Script:
echo "30" > /sys/class/misc/brightness_curve/min_bl
echo "1" > /sys/class/misc/brightness_curve/min_gamma
echo "20" > /sys/class/misc/brightness_curve/max_gamma
3) Gamma Shift
Significance: Gamma Correction
Gamma in the simplest form is a non linear operation to code and decode luminance of display systems. If display is not properly gamma encoded, human eye will not be able to differentiate highlights and details. Keep in mind that brightness perception of human eye is non-linear (ie, relationship between perceived brightness and luminance is non linear). Better perception is achieved at lower luminance level.
Use negative values for darker image system and positive values for brighter.
Sample Values: 0 (stock) or -15 (darker)
Valid Values: -50 to +50 (at steps of 1)
Tweaking Via Script:
echo "0" > /sys/class/lcd/panel/user_gamma_adjust
4) Vibration Intensity
Significance: Vibration Intensity for Notifications
You can change the intensity of vibration for calls, notifications, htpic feedback, etc. Change is most likely noticable only in aosp/aokp roms.
Sample Values: 6 (stock) or 2 (low intensity)
Valid Values: 0 to 6 pixels(at steps of 1)
Tweaking Via Script:
echo "6" > /sys/devices/platform/tspdrv/vibrator_level
TAB 4 - BLN: Backlight Notification and LED Timeout Settings
1) BLN
Significance: Notification for Missed Calls, SMSes, Emails, etc
GS2 doesn't have led notification built in. Instead the capacitive touch keys were hacked to lit up when some notification arrives.
Tweaking Via Script:
#ON
echo "1" > /sys/class/misc/notification/notification_enabled
#OFF
echo "0" > /sys/class/misc/notification/notification_enabled
2) Notification Timeout
Significance: Timeout for an Active BLN Notification
Timeout can be anything from a minute. Set it according to your taste and need.
Sample Values: 10 minutes
Valid Values: 1 minute to 2 hours to anything
Tweaking Via Script:
#In milli secs. Minutes*60*1000. Ex: For a 15 minute timeout set 15*60*1000 = 900000
echo "600000" > /sys/class/misc/notification/notification_timeout
3) BLN Effect
Significance: Pattern of Notification - breathe, static lights or blink
Breathing effect is achieved by supplying a lower to highest voltage at a particular step to backlight with a small pause/sleep in between. This is breathe Up. To breathe Down, voltage is supplied in the reverse order with a pause in between.
Tweaking Via Script:
#enable steady/static lights
echo "0" > /sys/class/misc/notification/breathing
#enable breathing/blinking
echo "1" > /sys/class/misc/notification/breathing
#breathing config - Min Voltage, Max Voltage (in mV), period/pause in between voltage changes (millisec), voltage step (mV)
echo "2500 3300 70 50" > /sys/class/misc/notification/breathing_steps
echo "3300 2500 70 50" > /sys/class/misc/notification/breathing_steps
#blinking config - set same voltages as min and max. It blinks
echo "2500 2500 500 100" > /sys/class/misc/notification/breathing_steps
echo "3300 3300 500 100" > /sys/class/misc/notification/breathing_steps
4) LED Timeout
Significance: Timeout for Backlights to stay On after touching buttons/screen
In Samsung roms, system settings can be used to achieve the same. Leave extweaks settings disabled for sammy roms. Since aosp roms do not have led timeout settings by default, use extweaks/script. If you want it always enabled, use settings in the rom.
Tweaking Via Script:
#backlights always off
echo "0" > /sys/class/misc/notification/led_timeout
#backlights turns off after a timeout after a touch. Unit - millisec
echo "1500" > /sys/class/misc/notification/led_timeout
5) LED Fadeout
Significance: Fadeout effect instead of LEDs normally turning off after touching buttons/screen.
Lights fading out can be an eye candy.
Tweaking Via Script:
echo "1" > /sys/class/misc/notification/led_fadeout
6) LED on Touch
Significance: Turn ON LEDs on Touching Screen
This is samsung default behavior but aosp/aokp roms miss this feature. If you like capacitive buttons to lit up on screen touch (along with buttons touch), enable this option.
Tweaking Via Script:
echo "1" > /sys/class/misc/notification/led_on_touch
7) Test BLN
Significance: Test BLN to see if everything works as you expected
Testing can be achieved by a script too like given below.
Tweaking Via Script:
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ "$SLEEPING" = "sleeping" ]; then
sleep 1
echo "1" > /sys/class/misc/notification/breathing_steps
8) LED Voltage Levels
Significance: Brightness of Touchkey Light
Minimum of 2550mV is required to lit up touchkey. Default is 3000mV. Max is 3300mV.
Tweaking Via Script:
echo "3000" > /sys/devices/virtual/sec/sec_touchkey/touchkey_brightness
TAB 5 - 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. Would be helpful to produce logcat and last_kmesg when you have a crash or freeze.
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
Tweaking Via Script:
echo "650 650 450" > /sys/devices/virtual/misc/charge_current/charge_current
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.
Randomly Asked Questions:
Q. "Why don't you just give a set of battery friendly or performance friendly tweaks to be used with ExTweaks app instead of lengthy sentences and crap?"
A. Three reasons: 1) Every device is different. 2) What i think are battery friendly/performance friendly settings may not please you. 3) It's useless to copy a setting without understanding what it does.
So i'm trying to give an almost accurate picture of effect of changing values of tweakable parameters. Then you will know what value and settings is best whether you're a battery-freak, performance-freak, 'I want it to be balanced'-freak. You will never have to ask in a thread "What is the best settings for this kernel".
Q. "What are the power domains i should be aware of so that i can think this way: Tweak settings related to each domain to make the most out of my kernel"
A. CPU cores (and L2 cache), GPU, Memory Interface and Audio/Video IP blocks
Q. "How about a short brief algorithm which explains working of hotplugging where i can see how are each parameters used."
A. Note the parameters with red font color. Those are the tweakable hotplug parameters mentioned above.
FUNCTION: standalone_hotplug()
Takes three parameters: load, min_rq, and minimum_cpu_run_queue_length
WORKING:
if ( both cores online AND [average_load < load_l1 OR current_cpu_frequency <= freq_min] ) RETURN HOTPLUG_OUT
else if ( only first core online AND average_load > load_h0 AND current_frequency > freq_min) RETURN HOTPLUG_IN
else if (both cores online AND min_rq < 2 AND load on the core corresponding to minimum_cpu_run_queue_length < load_rq) RETURN HOTPLUG_OUT;
SAMPLING PART:
Retrieve the value returned by standalone_hotplug by passing current load, min_rq and calculated minimum_cpu_run_queue_length
if (HOTPLUG_IN was returned AND second core is OFF)
Turn ON second CPU
Next sampling at 4 times the value of rate
else if (HOTPLUG_OUT was returned AND second core is ON)
Turn OFF second CPU
Next sampling at the value of rate

Exclusive Features
We will explore some of the exclusive features in ICS kernels, ofcourse brought in by XDA devs and not Samsung themselves.
Any feature is best explained through answers for different kind of questions. Atleast, that's what i believe
We have dual-booting and bln breathing to start with. Features are originally brought in by gokhanmoral and is available in a few kernels like Siyah as of now.
1. Dual Booting
1) "So what's dual booting?"
A. Option to boot into either of two ICS roms - aosp or sammy. Immediately after the boot logo, there is a 3 seconds time-out where you can boot into secondary rom by pressing the home key/volume down key. To boot into primary rom, wait for 3 seconds time-out to complete. If you don't like to wait - touch the screen, or press power key or press volume up key.
2) "What's the basic architecture behind dual booting?"
A. Any rom will have /system, /data, /cache partitions and requires a kernel to boot. Primary rom has all these partitions on the same location and partitions as if you were single-booting. ie, /dev/block/mmcblk0p09 for /system and rootfs for /data and /cache. Secondary rom uses a hidden partition (/dev/block/mmcblk0p12) for /system and sdcard to store /data and /cache partitions. They're stored in /sdcard/.secondrom directory as mountable ext4 block device images (data.img and cache.img).
Kernel partition is shared, so same kernel boots both the roms. If you switch from Siyah to a different kernel, dual booting will not be available even though there's a clone of secondary rom. Internal sdcard, external plastic sdcard, /efs, /emmc, other kernel related virtual filesystem directories, etc are shared among roms.
3) "I have just one rom now. How do i setup one more rom to dual boot?"
A.
-To use current rom as primary: Assuming the other rom is downloaded and copied to phone memory
Easy Method
i) Flash latest Siyah that supports dual boot.
ii) Wipe data and cache of second rom using format /secondrom_cache and format /secondrom_data options under dual boot menu in recovery.
iii) Flash rom zip as second rom directly using "Install zip to 2ndROM from internal SD" or "Install zip to 2ndROM from external SD" under dual-boot options in Recovery.
Old/Alternative Method if Easy Method fails
i) Flash latest Siyah that supports dual boot.
ii) Nandroid backup your existing rom.
iii) Full wipe, install the rom you need to dual boot into.
iv) Boot into that rom, perform initial setups, flash whatever zip you need to flash on that rom - gapps, themes, mods, etc.
v) Flash latest Siyah on this rom.
vi) Boot into recovery, under dual-boot options, select "Clone Primary ROM to Secondary". Be patient and wait about 6-7 minutes. Now the new rom is secondary rom.
vii) Within recovery, restore nandroid backup. Now, the existing rom becomes primary.
viii) Just to be sure, flash latest Siyah again.
-To use current rom as secondary: Assuming the other rom is downloaded and copied to phone memory
Easy Method
i) Flash latest Siyah that supports dual boot.
ii) Boot into recovery, under dual-boot options, select "Clone Primary ROM to Secondary". Now your existing rom becomes secondary.
iii) Full wipe and install the Rom you want to use as primary.
iv) Flash latest Siyah just to be sure.
Alternative Method
i) Flash latest Siyah that supports dual boot.
ii) Wipe data and cache of second rom using format /secondrom_cache and format /secondrom_data options under dual boot menu in recovery.
iii) Flash rom zip as second rom directly using "Install zip to 2ndROM from internal SD" or "Install zip to 2ndROM from external SD" under dual-boot options in Recovery.
iv) Select "Swap 1st Rom and 2nd Rom" under dual-boot options in recovery.
Now you have two roms. Press home key to boot into second rom when time-out is displayed.
4) "How much time was it to clone a rom?"
A. There's /system, /data/ and /cache to clone. 2 GB data + 103mb cache + 513 mb system = 2.6 gb
Shell prompt read speed = 7mb per second.
Total Time = 2.6*(1024/7) = 380 secs = 6/7 minutes.
5) "If i reboot to recovery from power-off state using 3 button method, to which rom's recovery it's booted into?"
A. Unified kernel, same recovery. And remember - flashing zips to second rom is not possible as of now.
6) "Any solution to flashing zips to secondary rom?"
A.
Yes. Use Install zip to 2ndROM from internal SD" or "Install zip to 2ndROM from external SD" under dual-boot options in Recovery.
Alternative 1:
If you know what the updater script in the zip is doing, you can do that manually using Root Explorer (replacing/copy files, setting permissions, etc).
Alternative2:
i) Swap 1st Rom and 2nd Rom using Dual-boot options in recovery. Now your 2nd rom becomes primary for time being.
ii) Install zips like normal.
ii) Swap again.
7) "Should i have same versions of kernels on both roms? If not, from which rom should i flash the kernel"
A. Flash kernel from any rom (if cwm app/darkyota is used). Both uses the same kernel partition anyway.
8) "Will i get a prompt to dual-boot if i'm not using dual boot, as in i haven't cloned any rom to use as secondary?"
A. NO
9) "I don't like waiting for 3 seconds to boot into primary rom."
A. Touch the screen/press volume up key immediately upon prompt.
10) "How to undo dual booting?"
A. Use "Remove 2ndRom" from dual-boot options in recovery.
11) "How to remove secondary rom if "Remove 2ndRom" in touch recovery fails for some reason?"
A. Format 2nrom /system partition from dualboot options in recovery, remove data.img and cache.img under /sdcard/.secondrom directory manually by booting into primary rom. Also delete /secondrom directory.
12) "So if at all i format /sdcard, my second rom is gone?"
A. Yes
13) "Is the size of /system partition of secondary rom re-sizable from user space?"
A. NO
14) "Can i have both aosp roms/both samsung roms/first aosp, second samsung/first samsung,second aosp?"
A. Yes
15) "Can i have one GB rom and second ICS rom?"
A. No
16) "Why?"
A. Kernel partition is shared between roms. Dual boot functionality is implemented in ICS kernel. ICS kernel can run only ICS roms.
17) "Can i have different kernels for the two roms?"
A. NO. Kernel partition is shared.
18) "USB mass storage works?"
A. Yes. Both cards will be mounted for primary and secondary roms. MTP works too.
19) "If i had the same /data partition shared between roms, i could use same apps on both roms."
A. Data partition can not be shared as they're incompatible between roms. (Sometimes dev asks you to perform full wipe even if you're switching between versions of the same rom right). Even if they were shared, separate dalvik caches has to be used and hence every boot will take a long time to rebuild dalvik.
20) "How do i swap primary and secondary roms?"
A.
Easy Way:
In recovery, select "Swap 1stRom and 2ndRom". It may take upto 20 minutes. Be patient and watch the progress bar.
Difficult way: If the "swap" in recovery fails,
i) Select "Backup secondary rom" under dual boot options.
ii) Under original Backup and Restore option, select "Backup" to nandroid backup your primary rom.
iii) Under dual boot options, "Restore as secondary rom" or "Restore as secondary rom from internal sd" and select the nandroid backup of what was actually your primary rom.
iv) Under original Backup and Restore option, select "Restore" to restore the rom you backed up as secondary.
21) "How to upgrade primary rom?"
A. As usual, goto recovery, wipe whatever you need to wipe and install the new version. Remember to flash latest Siyah after upgrading if the Rom comes with a different kernel.
22) "How to upgrade secondary rom?"
A. Use "Install zip to 2ndROM from internal SD" or "Install zip to 2ndROM from external SD" under dual-boot options in Recovery. to flash the Rom zip. If any wipe is required, use format /secondrom_cache, format /secondrom_dalivkcache, format /secondrom_data and format /secondrom_system under Mounts & Storage in recovery.
Alternative 1, if the above fails:
Temporarily convert secondary rom to primary (by swapping them in recovery), flash rom zip revert primary back to secondary by swapping again. Remember to flash latest Siyah after upgrading. (This is just to be sure. Flashing zip to second rom does not change kernel)
23) "How to replace secondary rom with another?"
A.
Easy Way:
i) Wipe second rom partitions using format /secondrom_cache, format /secondrom_dalivkcache, format /secondrom_data and format /secondrom_system.
ii) Install Rom zip using Install Zip to 2ndROM from internal SD or external SD from dual-boot options in recovery.
Difficult Way:
Perform the steps to setup dual boot as if you had only one rom which is going to be used as primary rom.
24) "How to replace primary rom with another?"
A. Normal procedure - wipe, install from recovery.
25) "Are init.d scripts and extweaks profiles shared across the roms so that i can make changes by booting into any rom and the other rom automatically inherits the settings?"
A. NO. Roms have differet /system partitions so different init.d directories. Roms uses different /data partitions so different extweaks settings since extweaks profiles are stored under /data/.siyah. Configure both separately. Initramfs scripts are shared anyway because Roms use the same kernel.
26) "Can i use titanium to backup and restore apps on both roms?"
A. Yes. With the default settings of titanium backup, it uses /sdcard/TitaniumBackup directoryto backup apps. Assume you have the same app installed in both roms and you backed up the app from both roms. Then when you restore app+data, the last backup is restored. (regardless of from which rom was it backed up last. Because the app database is overwritten for each backup). If you want to maintain exclusiveness between apps in the two roms, use a different backup directory in second rom. Reason for exclusivity could be - you need different settings for same app in the roms OR you have reached level 2 of a game in rom1 and level 6 in rom2 and you need to maintain that, etc.
27) "What're the Dual Boot options available in touch recovery?"
A.
i) View Current Status
Displays secondary rom info if found.
ii) Clone 1stRom to 2ndRom
First time, you will have only one rom. You may clone it as secondary rom (so that another rom can be used as primary). Note that what was Primary rom will remain as Primary after this. In short - you will copy of same rom and 1st and 2nd.
iii) Clone 2ndRom to 1stRom
Whatever has been cloned as second Rom is cloned to first rom. Note that what was Second rom will remain as Second after this. In short - you will copy of same rom and 1st and 2nd.
iv) Remove 2ndRom
Remove second Rom by Deleting /system, /data and /cache partitions of second rom. You will have normal booting.
v) Swap 1stROM and 2ndROM
Swaps primary and secondary roms by exclusively overwriting /system /data and /cache of both roms. This is a time consuming process. Be patient.
vi) Backup 2ndROM
Nandroid backup secondary rom to external sd.
vii) Restore as secondary rom
Restore any nandroid backup as secondary rom from external sd.
viii) Backup 2ndROM to internal SD
Nandroid backup secondary rom to internal sd.
ix) Restore as 2ndROM from internal sd
Restore any nandroid backup as secondary rom from internal sd.
x) init second rom data
Initialize /data parition of secondary rom to resize the partition to make it bigger in case you run out of space for apps. Init also wipes all the data in /data partition. So your existing apps in secondary rom will be gone.
xi) wipe second rom davik cache, xii) fix permissions in second rom - self explanatory
xiii) Install Zip to 2ndROM from Internal SD xiv) Install Zip to 2ndROM from External SD- self explanatory
xv) Wipe options for Second ROM can be found under Mounts and Storage - / format /secondrom_cache, format /secondrom_dalivkcache, format /secondrom_data and format /secondrom_system.
Mounting partition options for 2nd ROM can also be found there.
28) Why is "cloning 1stROM to 2ndROM" slower than "cloning 2ndROM to 1stROM"?
A. While cloning primary to secondary, it writes data.img and cache.img to internal sd card. While cloning secondary to primary, the images are written to device memory or rootfs. This is faster than writing to a mounted storage.
29) "Why can't internal SD be mounted with secondary rom whether it's sammy or aosp?"
A. It works now.
/data and /cache partitions of secondary rom resides in the internal sd. (/sdcard/.secondrom). So internal sd can not be unmounted to mount it to the PC. MTP works for internal SD too. Even though slower, that's the only option we got.
30) "After setting up Second Rom, i don't see a prompt to boot into second rom".
A. Try wiping Second Rom Cache and Dalvik.
31. "Before wiping 2ndROM data/cache, i had some free space on internal sdcard. During wipe it failed and that space has dissipated. Even after a successful wipe, the space is still lost."
A. Try (1). If it fails, try (2)
1) Delete files in /sdcard/.secondrom directory.
2) The space was occupied by lost.dir in /sdcard. Delete contents in that directory and you have the space back now.
32. "What's happening when i wipe /data and /cache of 2ndROM during the first time setup of dual boot?"
A. Two empty mountable EXT4 images - data.img and cache.img are created in /sdcard/.secondrom. While flashing zips to second rom, /data and /cache of second rom needs to be mounted in respective mmcblk. This empty .img files helps zip flashing without having the trouble to create them first.
33. "Will flashing a rom zip to second rom (when i already have dual booting) change kernel? I may lose dual boot if so."
A. NO. Flashing kernel is prevented for second rom if the zip contains a kernel.
34. "I lost dual booting after i flashed primary rom via odin". I flashed kernel again. I could see files in /sdcard/.secondrom. But no dual boot. Help"
A. Some carrier branded firmwares and such may wipe and push some apks and csc stuffs to the hidden partition used as /system of second rom. About 100 MB is used i think. After first reboot, it's never used again, but now you have lost /system of second rom even though data and cache are intact in SD.
Copy data.img and cache.img of secondrom from /sdcard/.secondrom to PC. Then modify your zip installer of your second rom to install only /system of second rom. (Edit updater-script in the zip to comment out lines that write to /data).
Now full wipe second rom /data and /cache. Format second rom /system. Flash the modified zip to second rom. Copy back and replace data.img and cache.img from your PC. Second rom should be intact now.
2. BLN Breathing
Q. What's bln breathing?
A: With BLN apps like bln control pro, we could set lights to be statically lit or blink when a notification arrives. A third effect could be achieved - breathing. Lights can follow a pattern to Fade In and Fade Out. Infinite possibilities exist for pattern since the tunables that control breathing can be set from the user space.
Q. How is breathing achieved?
A: A series of incidents using three principles: Vary LED voltage level from a Min to Max and then Max to Min, Pause between voltage changes, Supply a different voltage as next voltage defined by a voltage step.
Q. Make it more clear?
A. Let's take an example.
echo "2500 3300 70 50" > /sys/class/misc/notification/breathing_steps
echo "3300 2500 70 50" > /sys/class/misc/notification/breathing_steps
First two parameters defines star and end voltages/ min and max voltage (unit millivolts). Third parameter is the period or pause (in milliseconds) between voltage changes. Last parameter is the voltage step in millivolts.
As you notice, there's on more echo statement which reverse the voltage limits. This is because breathing is asymmetric. So commands for Fade IN (light on) and Fade OUT (light off) need to be written separately.
Some points to note:
-2550 is the minimum voltage to turn LEDs On.
-3300 is the maximum voltage that's supported by regulator.
-2500 is the minimum voltage supported by kernel as the least among valid voltage.
-Period should be echoed as milli seconds.
-Voltage step should be a multiple of 50.
Small Tutorial: Suppose you need a pattern - short, long, short breathes. Let's call this .._ When a notification arrive, it will repeat until notification times out .._ .._ .._
#First enable breathing:
echo "1" > /sys/class/misc/notification/breathing
#Reset existing pattern:
echo "reset" > /sys/class/misc/notification/breathing_steps
#Now echo as many FADE INs and FADE OUTs you need. The file will parse all these without overwriting. (If you cat the file, it may return only last echoed line. Don't worry)
echo 2600 3300 30 150 > /sys/devices/virtual/misc/notification/breathing_steps //short breathe achieved using lower period and higher voltage steps
echo 3300 2600 30 150 > /sys/devices/virtual/misc/notification/breathing_steps //fade out for short breathe by swapping voltage limits
echo 2500 3300 60 50 > /sys/devices/virtual/misc/notification/breathing_steps //long breathe achieved by increasing period and decreasing voltage step
echo 3300 2500 60 50 > /sys/devices/virtual/misc/notification/breathing_steps //fade out for longer breathe
echo 2600 3300 40 150 > /sys/devices/virtual/misc/notification/breathing_steps //another short breathe
echo 3300 2600 40 150 > /sys/devices/virtual/misc/notification/breathing_steps //fade out
echo 2500 2500 400 50 > /sys/devices/virtual/misc/notification/breathing_steps //Having same voltage limit (that too 2500 which won't turn on led) and some period means a pause between breathing cycles. This will give a relaxed effect.
Q. How can i achieve blinking?
A. Echo same voltage as min and max voltage for Fade in and Fade out effects.
echo "2500 2500 500 100" > /sys/class/misc/notification/breathing_steps
echo "3300 3300 500 100" > /sys/class/misc/notification/breathing_steps
Reducing the period to a smaller number say 100, gives you a faster blinking - a pulse effect.

New Governor(s)
Pegasusq Governor
Let's see what is pegasusq governor from Samsung which claims to be a multi core aware governor.
Some Basics to Remember Before Reading On:
Some patience is required to understand a governor.
Pegasusq is basically an ondemand based governor which also controls hotplugging.
Run Queue: We know mutiple processes can run at once on our device. These active processes are placed in an array called a run queue along with their priority values. (Priority is used by the task scheduler to determine which process is to run next) To ensure each process has a fair share of resources, each one is run for some time period then paused and placed back into the run queue. When a program is stopped to let another run - the program with the highest priority in the run queue is then allowed to execute.
Talking w.r.t to Android O.S and GS2 CPU, each core is given a run queue, which maintains both an active and expired array of processes. The scheduler selects the next process from the active array with highest priority. When a process' time period expires, it is placed into the expired array with some priority. When the active array contains no more processes, the scheduler swaps the active and expired arrays.
Wall Time is the total up time of CPU. Idle Time is the total idle time of the CPU. The difference (wall time minus idle time) gives CPU Busy Time. Load on CPU is calculated as percentage of Busy Time on Up Time. (Doesn't it make a lot of sense). Now you know exactly how is load measured.
Governor doesn't scale CPU but tells the CPU driver to do so.
Sampling means to evaluate load.
Smooth scaling is also done by CPU driver, not by governor.
Switching to pegasusq will deactivate Stand Hotplug since we don't need two logics to do the same thing at the same time and create conflicts.
Switching to a different governor from Stand hotplug will re-activate Stand Hotplug since we need a logic to control hotplugging.
Use scripts or SetCpu to change governor tunables.
Gokhanmoral modified pegasusq (originally authored by Samsung for quad core devices) in Siyah kernel to be dual core friendly.
Parameters:-
1) sampling_rate - Measured in uS and actual meaning being Sampling Interval, this factor determines how often the governor should poll for CPU usage in terms of frequency and load percentage to make scaling decisions - either scale CPU Up or scale it Down.
UNIT: Miscroseconds
2) up_threshold - Measured as percentage, when load on CPU is equal to above up threshold, CPU is scaled Up. Lower value - early scale up, and vice-verse.
UNIT: Percentage
3) sampling_down_factor - Acts as a multiplier for sampling interval for re-evaluating the load when CPU is truly busy and is on highest clock frequency (policy max). Setting to 1 makes no difference and causes CPU to immediately scale down from highest frequency. Sampling down factor is NOT valid for lower frequencies and low load conditions. Note that CPU is scaled up to max frequency when max_load_freq is greater than up_threshold*current frequency. (or to cur_freq + (freq_step * policy.max_freq) whichever is smaller) Max_load_freq is an arbitrary frequency calculated as the maximum of load_frequencies. Load_frequency is an arbitrary frequency which describes the frequency the device theoretically needs to handle 100% load, calculated as load*average_frequency.
To sum up, use non-zero sampling_down_factor to avoid governor jumping down to lower frequency even on high CPU load.
UNIT: Positive Integer
4) down_differential - After spending sampling_down_factor*sampling_rate micro seconds at maximum frequency on high load, governor samples the load again to calculate an approx target frequency to scale-down-to which should not trigger up_threshold in the next sample. (Triggering up threshold may cause jumping to max frequency again). Max_load_freq is checked against (up_threshold - down_differential) * current frequency. If found to be smaller, CPU is scaled down to a target frequency as described above. Down_differential also act as the factor to prevent aggressive scale down.
Higher value of down_differential corresponds to delayed scaling down.
UNIT: Positive Integer
5) freq_step - Defines how much as a percentage of maximum frequency, governor should increase CPU frequency each time CPU load reaches up_threshold.
UNIT: Percentage
6) cpu_up_rate - No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
7) cpu_down_rate - No of samples to evaluate load to scale CPU Down. After CPU_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
8) hotplug_freq_1_1 - Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and run queue length is greater than hotplug_rq_1_1) Hotplug IN Second Core. Higher value correpsonds to delay in turning on second core.
UNIT: Kilo Hertz
9) hotplug_freq_2_0 - Down threshold frequency to turn second core Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and run queue length is less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core. Lower value correpsonds to delay in turning off second core.
UNIT: Kilo Hertz
10) hotplug_rq_1_1 - Threshold run queue length for second core to turn on.
UNIT: Positive Integer
11) hotplug_rq_2_0 - Threshold run queue length for second core to turn off.
UNIT: Positive Integer
12) freq_for_responsiveness - Until freq_for_responsiveness, Up Threshold considered for sampling load is up_threshold_at_min_freq. Also during the part where CPU is at maximum load frequency, governor need to find the optimal frequency as the next frequency - which should not trigger up_threshold in the next sampling. When such a frequency_next is found to be a) less than freq_for_responsiveness b) will not trigger down_threshold in the next sample, then the optimal frequency is set to freq_for_responsiveness.
13) up_threshold_at_min_freq - This threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. Again, during calculation of optimal frequency which should not trigger up policy, down threshold to consider is difference between up_threshold_at_min_freq and down_differential
14) ignore_nice_load - Setting to 1 causes governor to ignore load resulted by nice processes while making scaling decisions. Nice processes are the one i/o scheduler refers to as low priority process.
UNIT: Boolean 1 or 0
15) io_is_busy - Setting to 1 causes treating i/o wait time as CPU busy time. I/O busy is just an indication that CPU is performance critical, and system is not actually idle. IO wait time is excluded from the CPU idle time value is 1.
UNIT: Boolean 1 or 0
16) max_cpu_lock - If set to zero, hotplugs in and out second core when appropriate. Otherwise specifies no of cores to be considered for hotplugging. Leave it as default 0.
UNIT: Integer 0/1/2
17) hotplug_lock - Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock for a non-zero value. Leave it as 0.
UNIT: Integer 0/1/2
18) *cpu_up_freq - Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
19) *cpu_down_freq - Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
20) *up_nr_cpus - Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.
UNIT: Integer 1/2
21) dvfs_debug - Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.
UNIT: Boolean 1 or 0
* - Parameters removed in siyah kernel since they're not actually used in the governor code.
Sample Tweaks:-
Assuming - i) You have 18 steps freq table ii) Scaling min is not greater than 200 mhziii) Scaling max is not less than 1000 mhz
Aggressive
Code:
echo "75" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
echo "65" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold_at_min_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
echo "60" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_step
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_for_responsiveness
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_up_rate
echo "20" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_down_rate
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_1_1
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_2_0
echo "200" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_1_1
echo "150" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_2_0
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/ignore_nice_load
echo "1" > /sys/devices/system/cpu/cpufreq/pegasusq/io_is_busy
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/max_cpu_lock
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_lock
Relaxed
Code:
echo "90" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
echo "80" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold_at_min_freq
echo "60000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
echo "20" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_step
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_for_responsiveness
echo "15" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_up_rate
echo "15" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_down_rate
echo "500000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_1_1
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_2_0
echo "350" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_1_1
echo "200" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_2_0
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/ignore_nice_load
echo "1" > /sys/devices/system/cpu/cpufreq/pegasusq/io_is_busy
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/max_cpu_lock
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_lock
My Settings: I don't want unnecessary power drain, and don't want lag to save extra juice. Scaling from 200 to 1200 with every frequency that's multiple of 100 in the table.
Code:
echo "80" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
echo "40" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold_at_min_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
echo "40" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_step
echo "200000" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_for_responsiveness
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_up_rate
echo "20" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_down_rate
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_1_1
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_2_0
echo "300" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_1_1
echo "200" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_2_0
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/ignore_nice_load
echo "1" > /sys/devices/system/cpu/cpufreq/pegasusq/io_is_busy
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/max_cpu_lock
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_lock
Once again, note that stand hotplug is disabled when pegasusq is active. After setting your values, just make sure you didn't configure pegasusq wrong where only one core is on all the time or both cores are online all the time. Open tegrak second core app and make sure second core turns on when needed and turns off when done.
Points to Note While Tweaking Pegasusq:-
1) Actual sampling interval is not the value of sampling_rate since load is evaluated after cpu_up_rate number-of-samples while scaling up and cpu_down_rate times number of samples while scaling down. So don't go for big values for sampling_rate. You're not saving battery but causing lags.
2) Always make sure that directly related parameters are rightly configured. For example a sampling_rate of 50000, cpu_up_rate of 10, cpu_down_rate of 20 means load is sampled after 10*50000=1000000=1 second for scale up and 20*50000=2 seconds for scale down.
3) Let value of down_differential always be between 5 and 10. Atleast 5 and 15. The difference between upthreshold and down_differential is considered as the percentage against current frequency to find a frequency to scale down to when CPU was on max_load_frequency. (This max_load_frequency is not your scaling_max_frequency. It's an arbitrary freq which is something smaller than that)
4) We know frequency jumps straight to max a little too often with ondemand based governors. One situation where this could happen is when max_load_freq is found to be greater than up_threshold percentage of current frequency. (If current frequency + (freq_step * policy.max_freq) is smaller than max frequency, it will jump to this frequency instead). So it's better not to go with very low up_threshold.
5) sampling down factor is the number of samples to spend at highest CPU frequency before re-evaluating the load. Setting to 1 may be battery friendly but also causes scale down even if CPU was very busy. A trade-off value is 2. High sampling_down_factor is not recommended. We don't need CPU to stay at highest freq forever.
6) Setting freq_step = 100% voids the reason for it to exist. Let it be something between 20% and 50% / 60% depending on your need. Note that smooth_scaling and freq_step does the same thing. Use only one of them at a time.
7) Hotplug up frequency (hotplug_freq_1_1) should be greater than hotplug down frequency (hotplug_freq_2_0). Also, hotplug_down frequency should be greater than your scaling minimum frequency. Else second core might not turn off after it kicks in.
8) Hotplug runqueues values affects second core activate/deactivate decisions based on no of threads running or no of processes kept in run queue. Let their values be between 200 and 350. If you need second to turn on quickly and turn off slowly, use low values for up rq and down rq.
9) freq_for_responsiveness is the frequency that aids in recalculating a frequency_next to scale down to from maximum frequency. When i) that frequency_next is found to be less than value of freq_for_responsiveness and ii) if by scaling down to that frequency, next sample won't cause a scale down, then the frequency_next is set to freq_for_responsiveness. (This prevents scaling down to a low frequency where next sample will cause a scale up). A frequency in the bottom half of your frequency table is a sensible value for this parameter. To disable use of this param, set it to your scaling minimum frequency.
10) up_threshold_at_min_freq is the up threshold for frequencies below freq_for_responsiveness. Value of this should depend on how low or high your freq_for_responsiveness is. If you need relaxed scaling till freq_for_responsiveness, use higher values for up_threshold_at_min_freq. And vice-verse.

Kmemhelper Binary - Virtual Kernel Hacking
kmemhelper
Warning: Slightly advanced topic. It's not so easy to understand, not so difficult either.
kmemhelper is a binary which you may use in scripts or adb to change values of some global static variables which in turn changes some parameters. Now, what's so special about it? We don't need to wait for device files and misc files as interfaces to parse the values we echo - to change some settings. Instead, the global static symbols in the kernel can be directly controlled by kmemhelper and create wonders.
Examples include changing smooth scaling param, change bus frequencies, change CPU internal voltages, change different touch thresholds and parameters, change touch frequencies, etc. Possibilities are quite large, provided you know the name of the variables, their type and valid values. You can find kmem binary in /system/xbin. Permissions should be 755.
Without waiting for change in kernel code to support certain settings changes, we simply use kmemhelper to have better control on many settings and features.
Working:
kmemhelper takes atleast four arguments.
Ex: kmemhelper -n smooth_level -t int
Modifier n refers to Name of the symbol. Modifier t refers to Type of the symbol. Above example echoes back the value of the variable "smooth_level" which is an integer. If you need to set a value for this variable, specify it as the last argument.
kmemhelper -n smooth_level -t int 8
This set smooth_level to 8 which is L8 in the frequency table. In an 18 steps frequency table, this is 800 mhz.
If the static variable is a structure or single dimensional/multi dimensional arrays, we should use offsets to specify the variable(s) we're changing. Modifier o specifies offset.
Syntax is
PHP:
kmemhelper -n <var_name> -t <var_type> -o <offset_value> <new_variable_value>
PHP:
Ex: kmemhelper -n mxt224_data -t char -o 59 50
This line changes value of a character variable to 50, in struct mxt224_data. The character variable is at 59th byte offset in the struct.
Calculating Offset:
Depending on the position and type of variable in a struct/array, we need to calculate offset correctly before using them.
Offset sizes are:-
int - 4
short - 2
char - 1
pointers - 4
Suppose there's a
struct Xyz
{
int a;
char b;
int c;
short d;
}
To refer "a" use offset 4. To refer to b use offset 4+1=5, for c 9, d 11 etc.
For example in mxt224_data which is a struct defined in arch/arm/mach-exynos/mach-u1.c symbol to change the value of touch threshold can be referred as:
kmemhelper -n mxt224_data -t char -o 58 35
This changes value of touch threshold which is MXT224_THRESHOLD_BATT_INIT located at offset 58 in the struct to 35%.
I want to learn about more Configurable Symbols:
You can find them all by cating kallsyms
cat /proc/kallsyms
Suppose you found an interesting variable and you need to know more about it. What you can do is download the kernel source, navigate to its root directory and search for this variable name.
find /path/to/possible/dir/in/kernel -depth -exec grep <varname> {} +
Now you know the file which contains the symbol/variable. After browsing code and understanding what it does and it's possible values, use kmemhelper in a script to change the values.
Sometimes, on different builds, the names of some symbols may change especially if there are similar variables with different suffixes. In such cases, kallsysms can be used to find the exact symbol name.
Example: LVL=`cat /proc/kallsyms|grep " level\."|awk '{print $3}'`;kmemhelper -n $LVL -t int
As you can see kallsyms content is read to retrieve all symbols. We narrow down results by searching for symbols containing "level" in their names. We pipe this result to awk '{print $3}' which apply print action to all the lines for the third column. Now LVL will contain the symbol name which defines touch frequency (Frequency to which CPU jumps when the screen is touched). Symbol name may be level.23175. We use kmehlper to view the value. It may retun 11 which is L11 = 500mhz in the frequency table.
We use the same command to set a new value to change the touch frequency.
LVL=`cat /proc/kallsyms|grep " level\."|awk '{print $3}'`;kmemhelper -n $LVL -t int 14
This changes touch frequency to 200. If the scaling minimum frequency is 200 mhz, frequency won't jump on screen touch. (Look in voltage control or setcpu to confirm). This could save some battery.
Other Useful Symbols:
For mxt224_data struct, change these variables to alter touch responsiveness.
# offset 59: MXT224_THRESHOLD_BATT_INIT - touch threshold on battery
ex: kmemhelper -n mxt224_data -t char -o 59 50
# offset 60: MXT224_THRESHOLD_CHRG - touch threshold on charging
kmemhelper -n mxt224_data -t char -o 60 55
# offset 61: MXT224_NOISE_THRESHOLD_BATT - noise threshold battery
kmemhelper -n mxt224_data -t char -o 61 30
# offset 62: MXT224_NOISE_THRESHOLD_CHRG - noise threshold charge
kmemhelper -n mxt224_data -t char -o 62 40
# offset 63: MXT224_MOVFILTER_BATT - movfilter battery
kmemhelper -n mxt224_data -t char -o 63 11
# offset 64: MXT224_MOVFILTER_CHRG - movfilter charging
kmemhelper -n mxt224_data -t char -o 64 46
# offset 67: MXT224E_THRESHOLD_BATT - touch threshold battery for mxt224e chip
kmemhelper -n mxt224_data -t char -o 67 50
# offset 77: MXT224E_MOVFILTER_BATT - movfilter battery for mxt224e chip
kmemhelper -n mxt224_data -t char -o 77 46
-Smooth Scaling (Defined in arch/arm/mach-exynos/cpufreq.c)
symbol: smooth_level which is an integer
Takes frequency level values as input to define the smooth scaling frequency of governor.
-Bus Frequency (Defined in arch/arm/mach-exynos/busfreq.c)
symbol: exynos4_asv_volt which is an array of integers.
Takes voltage in mv as input
NOTE
1) If you echo wrong value, or specify wrong offset (thus pointing to a different symbol), it may cause crash/reboot.
2) To prevent echoing back the value to console while we're setting a symbol value , use output console as /dev/null 2>&1
Example: kmemhelper -n smooth_level -t int 8 > /dev/null 2>&1
if we use only > it will output stdout to that file
we have 3 standard i/o - stdin (0), stdout(1), stderr(2)
2>&1 implies to redirect error to out first, so that everything will be directed to /dev/null.
I will try adding more useful symbols with their purpose, type, offset and possible values.

Misc Faqs on Kernel Stuffs
Kernel users ask a lot of questions - be it development thread or discussion thread. With this post, i hope to aggregate many such questions and even more questions along with answers. I have arranged them randomly - in no particular order. There will be basic and advanced questions. Some answers may be short some may be too long. Try "ctrl+F" in your browser and search for a keyword. You may find the answer you're looking for.
1) "Is it possible to have different default governors for recovery and rom?"
A. Yes.
2) "Governor in recovery?"
A. Ondemand. Not changeable from userspace.
3) "Is there a separate I/O sheduler in recovery? Can it be diff from rom default?"
A. Yes, it can. To support huge amount of writes to sdcard (for ex: with dual boot options), devs may use a different i/o scheduler in recovery. Noop would be apt.
4) "Governor while charging phone when it's off?"
A. The governor is virtually powersave. Because while phone is off and is on charging - device and kernel is ON but there's no background processes running. So frequency will be locked to 200/100 mhz - depending on your lowest frequency.
Also, charging when device is on in airplane mode is almost equal to charging when device is off. Except cell radio, other background processes in airplane mode shouldn't be hogging CPU too much.
5) "Why is resetting extweaks profile recommended sometimes after a kernel flash?"
A. Your profiles are stored under /data/.siyah with ".profile" extension. ".active.profile" file under the same directory stores the name of your active profile. Contents in profiles are in the format "parameter"="<default_value> format. Sometimes there will be change in extweaks interface :-
i) Some new tunables were added
ii) Some tunables were removed
iii) Transposition of some tunables
iv) Default value of some tunable was changed.
When such a change occurs, your profiles should know it too so that it can contain all the parameters. That's why you have to reset profiles after a new kernel flash if it changes something in extweaks.
Resetting simply copies .profile files from /res/customconfig to /data/.siyah . You can do it manually using a file manager to avoid a reboot to recovery and back to rom. From recent versions, Gokhan auto detect changes in extweaks configuration between your existing & new kernel version to auto reset extweaks profile. The check is achieved by md5 sum checks between existing /res/customconfig/customconfig.xml and new one.
6) "How to change mount point for NTFS-sticks from /mnt/ntfs to another location for NTFS usb disks?"
A. Mounting ntfs sticks are managed by /sbin/hotplug script which is called on every plugging and unplugging operations and it includes usb sticks.
We can have an initd script which mounts rootfs in rw and replace that script to modify the location. Script should
1. mount -o remount,rw /
2. rm /sbin/hotplug
3. echo some lines to /sbin/hotplug to create the string you have prepared
4. chmod 755 /sbin/hotplug
7) "What happens if i set single/dual core mode and is on pegasusq?"
A. At the moment, pegausq override the setting and force system to dynamic hotplug mode. Anyhow, it is supposed to respect single core/dual core mode setup and behave like pure ondemand. Dev may make changes in the governor soon.
8) "I feel brightness is still high even at lowest brightness level while reading in dark?"
A. Reduce gamma using extweaks.
9)" Which hotplug logic is used with pegasusq?"
A. Stand hotplug which was introduced on ics which is multi thread aware. (Other hotplug logic is legacy hotplug which is default on gingerbread and is also available in ICS)
10) "Bln and testmode was working perfectly until a new kernel flash. Now there seems to be a problem."
A. Open extweaks. Disable bln - apply changes, enable bln - apply changes, reboot.
11) "What exactly is smooth scaling?"
A. Ondemand governor jumps straight to max frequency a little too often. We can control this by setting a smooth scaling frequency to which the CPU will scale to first before scaling to maximum frequency. A little power saving is the target here. Note that CPU driver does smooth scaling - not governor. When CPU driver is requested by governor to scale up to max frequency, it first scales to smooth frequency, and only in the next sampling to highest frequency. Smooth scaling atm is active for ondemand and pegasusq.
12) "What happens if i set smooth scaling freq to more than my scaling max frequency?"
A. Cpu driver will jump freq to that before scaling to max freq. So make sure you set it below max freq.
13) "How to insert a module that's available in /system/lib/modules?"
A. Safe to be root. In terminal or adb
su
insmod /lib/modules/<module_name.ko>
14) "How to know which modules are pre-loaded by kernel?"
A. Terminal or adb:
lsmod
15) "Why do i feel there's more wake up lag with ICS compared to gingerbread?"
A. ICS kernels has a resume time of 1000ms (one second) compared to 650ms in gingerbread. This time is just to resume the kernel from deep sleep. Note that a little more time is required to resume other background processes.
16) "I'm finding it difficult to underclock to below 800 mhz. Why?"
A. Frequency on GS2 is locked to 800mhz while entering and exiting deep sleep. Boot-loader resumes at 800mhz. Configuring this frequency at kernel level to something lower could cause a lot of SODs on many devices. Anyhow - your underclocking frequency shouldn't be below 800 mhz because of the mentioned reason.
17) "What is screen touch frequency?"
A. It's the frequency the CPU driver jumps CPU to when the screen is touched. Open voltage control/setcpu. Touch the screen and don't take off the finger. You can see CPU at 500mhz. This is the default in most of the custom kernels. Samsung default was 1000 mhz.
18) "Can i change touch screen frequency?"
A. Yes. With kmemhelper interface on supported kernels like Siyah.
You need to lower the frequency. Ideally to your scaling minimum frequency whether it's 100 or 200mhz. First find the level number of frequency from your freq table. Example: if you use 18 steps frequency table, L0=1600 L1=1500 L2=1400..... L14=200mhz L15=100mhz
Put this line in one of your init.d scripts
TF=`cat /proc/kallsyms|grep " level\."|awk '{print $3}'`;kmemhelper -n $TF -t int 14
Replace the last parameter - 14 with the level number of frequency you want to set. After executing this line, open voltage control again, touch screen and hold. You will see frequency did not jump and stayed at 200mhz.
19) "What are the basic things i should take care of when i echo my custom frequency steps to scaling_available_frequencies table?"
A. 1) Valid frequencies are 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 700, 600, 500, 400, 300, 200, 100, 50, 25 in Mhz.
2) Valid frequency is a multiple of four
3) If you're undervolting via an app or script,make sure you set proper voltages and enough voltage steps depending on your frequency step count. Wrongly parsed voltages may result in a non-booting device.
4) ExTweaks settings are applied only during initial boot stage. Any settings that uses frequency level numbers - L0, L1, etc etc should be properly configured to work with your new frequency steps. Best examples are Smooth Scaling parameters and governor settings (like lulzactive screen_off_min_step. Value is 5 in a 7 Step freq table points to a max cap of 500 mhz and max cap of 800mhz in a 9 step table.
5) You can not skip frequencies - 500, 800 and 1000 when you're echoing custom frequency steps.
20) "Why should Not we use high thresholds for hotplugging unlike we did on gingerbread"?
A.We have multiple hotplugging logics on ICS. One is Stand Hotplug (default in most of the ICS kernels) another one is Legacy Hotplug (this was also the logic in gingerbread).
In legacy hotplug (remember loadh, loadl, load_scroff, loadl_scroff etc on GB), the thresholds directly mapped to the current load percentages. At any frequency, if load on CPU is greater than loadh, second core will kick in.
But equations are different in stand hotplug. Stand hotplug aims to calculate load using current load and current frequency. It will make more sense looking at the load calculation equation.
Average Load = (current_frequency * load) / max_performance [where max_performance = max_frequency * no_of_cpus]
Ex: Assume current frequency = 500 mhz load = 70% and max frequency = 1200 mhz
=> average_load = (500*70) / (1200*2) = 23%.
From this it's obvious that second core would kick-in at a 70% load on CPU running at 500mhz only if load_h is set to 23% or less.
Let's calculate theoretically what's the max value for load_h that's valid.
To calculate highest average load, current frequency should be maximum (it should equal max freq) and load should be max (100%).
Highest Average Load = (MaxFreq*100) / (MaxFreq*2) = 50%. So theoretically, load_h can have a max value of 50%. You set anything above, second core won't turn on and the setup will work like single core mode. Practically, the values should be even lesser. I recommend using load_h= 25% and load_l = 10%.
21) "I don't see an init.d folder in my rom. I wanna create some initd scripts. What to do?"
A. Using a root explorer create init.d directory under /system/etc. Set perm 777.
22) "Difference between tar and cwm versions of kernels?"
A. No significant difference. Tar just has the raw kernel image - zimage which you can flash using cwm app/recovery/even adb. Zip has the same zimage with installation script that writes raw image to kernel partition.
23) "After flashing a new kernel i see there are some stuffs missing from extweaks"
A. Either the support for those missing tunables were removed or just the extweaks interface was removed. The parameters might still be accessible through scripts. Check the file path to make sure.
24) "How to know which hotplugging logic is used in the current kernel build?"
A. Navigate to /sys/module using a file explorer. If you find stand_hotplug directory, Stand Hotplug logic is used. If you find pm_hotplug directory instead, Legacy Hotplug is used.
Many more questions to come......

WOW
Why don't you build your own kernels?

sahibunlimited said:
WOW
Why don't you build your own kernels?
Click to expand...
Click to collapse
Because i like to spend my GS2-time tweaking and using the device rather than endlessly coding, making improvements and listen to mixed feedbacks from users
EDIT: After 10 minutes of opening thread, someone gave me a 1 star as first rating.

good stuff
I'll keep this handy the next time I finetune my own kernel.
Keep up the good work!

droidphile said:
Because i like to spend my GS2-time tweaking and using the device rather than endlessly coding, making improvements and listen to mixed feedbacks from users
EDIT: After 10 minutes of opening thread, someone gave me a 1 star as first rating.
Click to expand...
Click to collapse
Informative as always. Keep it up mate and very helpful as always threads that you make. Hopefully this becomes a sticky as it deserves to be. Thank you

Great thread mate, as its previous twin it will become another legend soon!
Sent from my SGS2 - Powered by CM9

Great info mista D. Im learning a lot thx to you man. Keep up with the excellent contributions. Topics like this got me stuck to xda. Thanks!
Sent from my GT-I9100 using XDA

Hmm.. seems legit.
Thanks for info. Great learning from you. =)

you are simply the best when it comes to kernels, your knowledge on kernels is outstanding!

Great topic !
A very best of ! Thanks for all those informations mate
Cheers

thank you
thank you very much for this, very well written and easy to understand, time to start putting some tweaks into action

I'm curious, all that:
echo XXX > /sys/devices/......
Where did you find those commands? Exist some kind of reference or is from a file in the kernel source?

droidphile said:
Because i like to spend my GS2-time tweaking and using the device rather than endlessly coding, making improvements and listen to mixed feedbacks from users
EDIT: After 10 minutes of opening thread, someone gave me a 1 star as first rating.
Click to expand...
Click to collapse
The one star guys is probably an ignorant idiot that didn't understand any word here. Awesome job.
Envoyé depuis mon GT-I9100 avec Tapatalk

i was hoping for a thread like this for a long time have tried extweaks in every position but now i know what i am actually doing
thanks!

hjuo said:
I'm curious, all that:
echo XXX > /sys/devices/......
Where did you find those commands? Exist some kind of reference or is from a file in the kernel source?
Click to expand...
Click to collapse
Some of the locations are same as in GB kernels. Rest we can search and find out. And yeah, even sources can help. For example, file that's responsible for hotplugging on ics is stand-hotplug.c; and there's a stand_hotplug directory under sysfs...

Great work, man. Very thorough, very informative.
screamworks.

Slow phone after screen turn on and lockscreen (CyanogenMod 7.2 + sd-ext)

Hello everybody!
I'm having a strange problem: if i have the phone locked, with screen turned off for a while, in my pocket, when i turn it on again it is very slow. It takes about 30 seconds to come back to usual performance.
For example, if i unlock the phone and i go to SMS or WhatsApp, the keyboard (Swiftkey) it's so slow that i have to wait for every word to complete, before i can type another one.
After 30 seconds from the unlock the phone works ok.
The problem started when i've upgraded from CyanogenMod 7.1 to CyanogenMod 7.2 and i've created an sd-ext partition (in ext3 format, on a class 6 SD) to move there some apps.
I've got an HTC Desire HD.
I noticed the same problem when i was using a MIUI rom with the CPU Tuner app: i supposed that it slowed down too much the CPU when the screen was locked, so that it took a lot to come back to normal performances. But, now, i don't have that app installed and, looking ad Exaile 2 when i unlock my phone, it seems that CPU frequencies it's a 1 Ghz and even RAM usage is ok.
What could it be?
I have to wipe and install CM 7.2 from scratch?
Or could it be the sd-ext partition with apps on?
Thank you in advance!

Try installing set CPU or CPU Tuner again and set the CPU to something high when the phone is asleep. If that then works and it is no longer laggy try reverting it to a lower speed.

Not sure about the sd ext partition,, but yes, try a full wipe and install 7.2.
Sent from a dream.

Just change the governor. Governor is interactive by default i think.
Had the same problem after weeks i just changed governor to ondemand and everything was prefect.
Sent from my Desire HD using Tapatalk 2

Try installing set CPU or CPU Tuner again and set the CPU to something high when the phone is asleep. If that then works and it is no longer laggy try reverting it to a lower speed.
Click to expand...
Click to collapse
When i had it, i never configured because i am too lazy
I'll give a try, thanks!
Not sure about the sd ext partition,, but yes, try a full wipe and install 7.2.
Click to expand...
Click to collapse
I do not really want to, but i think too that could be a good test
Just change the governor. Governor is interactive by default i think.
Had the same problem after weeks i just changed governor to ondemand and everything was prefect.
Click to expand...
Click to collapse
Good tip!
My governor is "interactive" too, infact. I'm changin it to "ondemand".
Does anyone have a table that explain the difference between governors?

I'm on ARHD and the same started all of a dudden a few months ago. I had the same governor and settings for months without change and this still started. I changed governors (ondemand, smoothass, smartass, etc.) but it still happens sometimes. Not ver often but sometimes.

sberla54 said:
Good tip!
My governor is "interactive" too, infact. I'm changin it to "ondemand".
Does anyone have a table that explain the difference between governors?
Click to expand...
Click to collapse
Here you go
7. CPU Scaling Governors
CPU governors control exactly how the CPU scales between your “max” and “min” set frequencies. Most kernels have “ondemand” and “performance.” The availability
ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
Click to expand...
Click to collapse
Here as well
CPUFreq governors in the Android Kernel
=======================================
+ performance
The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.
+ powersave
The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.
+ userspace
The CPUfreq governor "userspace" allows the user, or any userspace program running with UID "root", to set the CPU to a specific frequency by making a sysfs file "scaling_setspeed" available in the CPU-device directory.
+ ondemand
The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters: sampling_rate, show_sampling_rate_min, up_threshold, ignore_nice_load, sampling_down_factor.
+ conservative
The CPUfreq governor "conservative", much like the "ondemand" governor, sets the CPU depending on the current usage. It differs in behaviour in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the "ondemand" governor through sysfs with the addition of: freq_step & down_threshold
+ interactive
The CPUfreq governor "interactive" is designed for latency-sensitive, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However, the governor is more aggressive about scaling the CPU speed up in response to CPU-intensive activity. The tuneable value for this governor are: min_sample_time & go_maxspeed_load
+ smartass (By [email protected])
The smartass governor is a complete rewrite of the interactive governor. CPU spends much more time at the lower frequencies for improved battery life. It gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
+ savagedzen (By [email protected])
SavagedZen is a governor based on the Smartass governor. With tweaks to paramaters which control how much and how fast cpu ramps up/down. Main difference versus Smartass is that cpu ramps down not in fixed steps, but based on cpu load heuristics, i.e. when cpu load falls below threshold (min_cpu_load), cpu immediately ramps down to a frequency derived from the measured load.
+ interactiveX (By [email protected])
Modified version of interactive with suspend code which locks at lowest clock speed when screen is off. Has a sleep+awake profile, meaning you don't need to set up manual profiles, it will lock at your minimum frequency during screen off
Click to expand...
Click to collapse

andreasy said:
I'm on ARHD and the same started all of a dudden a few months ago. I had the same governor and settings for months without change and this still started. I changed governors (ondemand, smoothass, smartass, etc.) but it still happens sometimes. Not ver often but sometimes.
Click to expand...
Click to collapse
Me too i didn't changed the governor, but in my case, a ROM upgrade and a sd-ext creation are some major changes that can affect performances...
l33ch0r said:
Here you go
Here as well
Click to expand...
Click to collapse
Thank you l33ch0r!
There doesn't seem to be much difference between "ondemand" and "interactive"; regarding to this documentation, "interactive" seems more quick.
Anyway, i've changed my governor to "ondemand" and i must say that all yesterday the phone has been fast and responsive. I'll keep you updated!
Thank you very much!

[GUIDE] [DIY] Tweaking Voltages and Governors Using init.d Scripts

I am writing this guide to help you make your own init.d scripts which you can use to set voltages and fine tune governor settings at boot.
Part 1: Creating a return to stock flashable zip
Part 2: Creating a flashable zip to set a default governor
Part 3: Setting default CPU frequencies.
Part 4: Tweaking voltages
General Information on the smartassV2 governor
Part 5: Setting ideal sleep and wake frequencies for smartassV2
Part 6: Understanding max and min cpu load
Part 8: Setting CPU thresholds and ramp steps
Part 9: Up rate us and down rate us

Creating a return to stock flashable zip
I do not have any background in programming or engineering. Editing scripts is something I realized I could do after reading through the thread on the LeeDroid ROM.
I had been using apps to adjust voltage levels of the processor, and the settings would not stick past reboot. LeeDroid's post showed me how I could adjust "vdd_levels" in a different way: by editing a file in the system/etc/init.d setting of your phone.
I started by manually editing files using Root Explorer. The new settings would take effect on reboot. I recommend that you edit using editor in an Android app designed for the purpose, like Root Explorer. Editing Android text files with Windows notepad could remove UNIX coding.
Of course, a bad edit could result in a phone which would not boot or enter into boot loops. So if you plan to do this I recommend that you first create a return to stock zip.
If you have a zip which would restore the stock zip file that you plan to edit, at worst a bad setting creates a problem that can be fixed by a simple battery pull, and flashing the return to stock file.
So lets learn how to create a flashable zip with a return to stock file.
The file that needs to be edited for setting and tweaking governors and clocks speeds is normally:
1. 01sysctl
2. 07sysctl
3. 00start
4. Something else :silly:​A have created a blank template which you can edit and which you should download and edit as part of this tutorial.
DOWNLOAD THE ATTACHMENT (having dinner. feeding dog. will upload it after) .
1. After you download the attachment, unzip and lets start editing the files inside.
2. Open the folder returntostock-template and you will see two folders:
META-INF
system
3. First lets copy the file to plan to edit into the /returntostock-template/system/etc/init.d folder.
If you are planning to edit the system/etc/init.d/01sysctl file, copy 01sysctl and paste it in
/returntostock-template/system/etc/init.d/
When you flash the zip you are creating the contents of /returntostock-template/system/etc/init.d/ will be flashed into /system/etc/init.d/
4. No, go into the META-INF folder.
5. Open the file called CERT.SF with a text editor. It should looks something like this:
Signature-Version: 1.0
Created-By: 1.0 (Android SignApk)
SHA1-Digest-Manifest: UX+RVULxNdXlqI1RzwHfpVdI82E=
Name: META-INF/com/google/android/updater-script
SHA1-Digest: tVgqIpMRtv5B/PDrjuBV53KwFaE=
Name: system/etc/init.d/01sysctl
SHA1-Digest: ldESPD5zXoMgc1LeEoJzmQR64XI=
Name: META-INF/com/google/android/update-binary
SHA1-Digest: bgbIMYDdOmTgqY3FnKD5cRyGkrw=
Click to expand...
Click to collapse
I highlighted in bold the line you may have to change. If you are editing the 01sysctl file than you can leave it as is. If you are editing the 00start file you can change the line to read:
Name: system/etc/init.d/00start
Click to expand...
Click to collapse
6. Next, open the file called MANIFEST.MF. It should looks something like this:
Manifest-Version: 1.0
Created-By: 1.0 (Android SignApk)
Name: META-INF/com/google/android/updater-script
SHA1-Digest: buU2q9y9m+br7uS7p3pPrQBNAvs=
Name: system/etc/init.d/01sysctl
SHA1-Digest: vdvxtL6XYfchsrXx3EBnG+qNyXE=
Name: META-INF/com/google/android/update-binary
SHA1-Digest: lW3X0T93MyGESji9tYbY+94o+jo=
Click to expand...
Click to collapse
I highlighted in bold the line you may have to change. If you are editing the 01sysctl file than you can leave it as is. If you are editing the 00start file you can change the line to read:
Name: system/etc/init.d/00start
Click to expand...
Click to collapse
7. THIS LAST STEP IS OPTIONAL, BUT IT IS NICE TO PERSONALIZE YOUR WORK. Next, go into the com folder, and than the google folder and finally the android folder.
8. Open the file called updater-script with a text editor. What you should see should look like this:
#
# Updater-script
#
ui_print("Flashing process for NAME OF ROM HERE");
ui_print(">>>Mounting partitions");
assert(mount("ext3", "EMMC", "/dev/block/mmcblk0p25", "/system") || mount("ext4", "EMMC", "/dev/block/mmcblk0p25", "/system"));
ui_print(">>>Writing System");
package_extract_dir("system", "/system");
ui_print(">>>Unmounting partitions");
unmount("/system");
ui_print("Done!");
Click to expand...
Click to collapse
You can change the NAME OF ROM HERE to anything you like. It will be displayed when the script is flashed.
9. Okay, were almost done. You can rename the folder to returntostock-template to something which will remind you what it is like CoolICSROM-returntostock or anything else you like.
10. Zip the file, and it is ready to use.
Now lets make another flashable zip, this time to set a new default governor.

Creating a flashable zip to set a default governor
Having learned how to make a flashable zip from this post, we now have the tool to deploy the payload into you ROM from recovery. So lets deploy something :laugh: Lets make a flashable zip to set the governor.
1. Okay, lets unzip the return to stock zip you made. In our first guide we called it CoolICSROM-returntostock.zip. It will unzip into a folder of the name of your file. In our example the folder will be named CoolICSROM-returntostock.
2. Lets rename the folder boonkeat8-governortweak, or anything else you want.
3. Now, these scripts are really more like hidden settings. They do not add any functionality to your ROM, but allow to enable things already there. So first we should check what governors are supported by you ROM.
Browse to > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
You should see something like this
convervative interactive ondemand ondemandX lionheart lionheartX smartassV2​
Click to expand...
Click to collapse
What you see listed is what is available.
4. In order to enable a governor as default, you have to write this line into the 01syscl (or 00start or other file depending on the ROM). Let's say we want to use the smartassV2 governor.
This is the line of code you need to write to enable it.
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
5. Lets go into the boonkeat8-governortweak and browse to /system/etc/init.d folder. Open the 01sysctl, 00start or other file you place in there with a text editor.
6. The typical 01sysctl file looks something like this:
#!/system/bin/sh
# - sysctl -p​
Click to expand...
Click to collapse
7. So lets just insert the line so it looks like this:
#!/system/bin/sh
# - sysctl -p
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
8. Zip the boonkeat8-governortweak folder, and you now have a flashable zip to enable the smartassV2 governor.
xxxxxxxxxxxxxxxxx
The 00start start file in a ROM like TrickDroid looks more daunting.
#!/system/bin/sh
SCHEDULER=noop
echo $SCHEDULER > /sys/block/mtdblock25/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock26/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock27/queue/scheduler
echo $SCHEDULER > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/rotational
for i in 1 2 3 4 5
do
echo 0 > /sys/block/mtdblock$i/queue/rotational
done
sync
echo "3" > /proc/sys/vm/drop_caches
setprop dalvik.vm.execution-mode int:fast​
Click to expand...
Click to collapse
But you just to the same thing. Insert the line of code.
#!/system/bin/sh
SCHEDULER=noop
echo $SCHEDULER > /sys/block/mtdblock25/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock26/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock27/queue/scheduler
echo $SCHEDULER > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/rotational
for i in 1 2 3 4 5
do
echo 0 > /sys/block/mtdblock$i/queue/rotational
done
sync
echo "3" > /proc/sys/vm/drop_caches
setprop dalvik.vm.execution-mode int:fast
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
Lets mode on to setting default CPU frequencies.

Setting default CPU frequencies
I really hope someone is reading all this.
Okay, having learned how to set the default governor, lets move on to default processor speeds.
Right now our init.d configuration script looks something like this:
#!/system/bin/sh
# - sysctl -p
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
In order to change the default processor frequency, we have to first find out what is available.
You can do this by opening the scaling_available_frequencies file located in /sys/devices/system/cpu/cpu0/cpufreq.
The contents should look something like this:
122060 245760 368640 768000 806400 1024000 1200000 1401600 1497600 1708800 1804800 1900800 2016000​
Click to expand...
Click to collapse
245760 = 245 MHz
368640 = 368 MHz
768000 = 768 MHz
806400 = 806 MHz
1024000 = 1024 MHz
...and so on
REMEMBER, YOU ONLY NEED TO DO THIS IF YOU WANT TO CHANGE THE DEFAUL PROCESSOR SPEEDS.
To find out the the default processor speeds browse to:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - This tells you what the current maximum processor frequency is.
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq - This tells you what the current minimum processor frequency is.
The command to change the processor speeds are:
echo 'PROCESSOR SPEED HERE' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 'PROCESSOR SPEED HERE' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
So if we wanted to modify our current project to have a maximum speed of 1200 MHz, and a minimum speed of 368 MHz, we would modify our current file to look like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
If you only want to change the maximum frequency than just enter the line for that:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
Now, lets mess with voltages.

Changing voltages
Okay, we have learned how to make a flashable zip, change the default governor and change the default frequencies.
Before we get into how to adjust default voltages, one thing you should take into consideration is the most ROM's already have HTC default voltages for the Desire HD tweaked for efficiency.
HTC default voltages
245 MHz - 1000 vdd
422 MHz - 1025 vdd
806 MHz - 1100 vdd
1024 MHz - 1200 vdd
Source: LeeDrOiD HD Thread.
Typical stock voltage for most custom ROM's
245 MHz - 875-925 vdd
422 MHz - 900-950 vdd
806 MHz - 10125-1075 vdd
1024 MHz - 1050-1100 vdd
Given this situation reducing voltage is not all that important these days.
Anyway, lets discuss how to do it, and we can engage in discussions, and get feedbacks from users on the matter.
Checking your ROM's default voltages
Okay, lets fire up you file manager and browse to /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Image of vdd_levels file from ARHD 6.3.3.
Image of vdd_levels file from Blackout ICS v.3.1.1 modified with Blackout-smartassV2-1GHz-c3.zip.
Changing the voltage
The command for changing voltage is:
echo 'FREQUENCY VDD' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
When running the 1200 MHz speed I find my phone can run this speed as low as 1100MHz. I learned this while running ARHD6.3.3.
In order to set that voltage you would need this command:
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
Adding it to our current project
Our current project looks something like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
Thats all there is too it.
Now lets go and tweak smartassV2.

General information on the smartassV2 governor
Governors are of all types generally to be based on one of two sources: ondemand and conservative.
smartassV2 for example is based on ondemand.
Other popular governors like lionheartX are based on the conservative governor.
Okay, lets start with smartassV2
General info:
SmartassV2 "has an 'ideal' frequency which it will quickly ramp up to, then more slowly ramp up once past it, and vice-versa for down-ramping. A separate "ideal" frequency is used when the screen is off."
Click to expand...
Click to collapse
(Source)
The most important tunable is the "ideal" frequency: this governor will aim for this frequency, in the sense that it will ramp towards this frequency much more aggresively than beyond it - both when ramping up from below this frequency and when ramping down from above this frequency. Still, note, that when load is low enough the governor should choose the lowest available frequency regardless of the ideal frequency and similarly when load is consistently high enough the highest available frequency will be used.
Smartass also tracks the state of the screen, and when screen is off (a.k.a sleep or suspended in the terms of this governor) a different ideal frequency is used. This is the only difference between the screen on and screen off states. Proper tuning of the awake_ideal_freq and sleep_ideal_freq should allow both high responsiveness when screen is on and utilizing the low frequency range when load is low, especially when screen is off
Click to expand...
Click to collapse
(Source).
Tunables (Source)
awake_ideal_freq
The "ideal" frequency to use when awake. The governor will ramp up faster towards the ideal frequency and slower after it has passed it. Similarly, lowering the frequency towards the ideal frequency is faster than below it.
sleep_ideal_freq
The "ideal" frequency to use when suspended. When set to 0, the governor will not track the suspended state (meaning that practically when sleep_ideal_freq =0 the awake_ideal_freq is used also when suspended).
sleep_wakeup_freq
The frequency to set when waking up from sleep.When sleep_ideal_freq=0 this will have no effect.
ramp_up_step
Frequency delta 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.
ramp_down_step
Frequency delta when ramping down below the ideal freqeuncy. Zero disables and will calculate ramp down according to load heuristic. When above the ideal freqeuncy we always ramp down to the ideal freq.
max_cpu_load
CPU freq will be increased if measured load > max_cpu_load;
min_cpu_load
CPU freq will be decreased if measured load < min_cpu_load;
up_rate_us
The minimum amount of time to spend at a frequency before we can ramp up. Notice we ignore this when we are below the ideal frequency.
down_rate_us
The minimum amount of time to spend at a frequency before we can ramp down. Notice we ignore this when we are above the ideal frequency.
sample_rate_jiffies
Sampling rate, I highly recommend to leave it at 2.
Click to expand...
Click to collapse

Setting ideal sleep and wake frequencies for smartassV2.
Wake, sleep and deepsleep
Your basic governor is on demand and it runs your processor from the slowest speed to the fastest speed, depending on "need". With a HTC Desire HD, typically the slow speed for a ROM at stock settings is around 245MHz and the fastest is at about 1024 MHz.
Need is determined by something called the max_cpu_load setting. But we will get back to the in a later post.
What differentiates smartassV2 is the addition of two settings to your basic ondemand governor:
awake_ideal_frequency
sleep_ideal_frequency
You will find the smartassV2 settings in /sys/devices/system/cpu/cpu0/cpufreq/smartass
awake_ideal_frequency - This setting will influence processor behavior when screen is on.
sleep_ideal_frequency - This setting will influence processor behavior when screen is off. Basically, when the phone is working in the background.
Deep sleep - The kernel is in charge.
Speed brakes
So lest say, maximum cpu frequency is set to 1024 MHz. This is the fastest the phone will run.
Typically, awake_ideal_frequency will be set at 800000 (meaning 800 MHz). This is the speed which the phone will ramp up fast to. After this the processor will still speed up, but more conservatively.
So lets say the ROM we are using has the following frequencies available:
245 - 368 - 768 - 806 - 1024 MHz.
When the screen is awake, the phone will go from 245 MHz to 368 MHz to 768 MHz and 806 MHz "fast"... but will take more time before deciding to go to 1024 MHz. Think of it as a setting which starts to apply brakes to the CPU's and try to slow down the CPU's progress.
So basically the lower the awake_ideal_frequency the more conservative the processor behavior will be. This should result in better battery life, but also poorer performance.
sleep_ideal_frequency
sleep_ideal_frequency works the same way, but it replaces the awake_ideal_frequency when the screen if off,
Typical sleep_ideal_frequency is between 200000 to 400000 (200 MHz to 400 MHz) so it applies the brakes sooner.
This is based on the theory that while the screen if off, even if it is working, it needs less power.
Back to are project
We left our project looking like this in the previous post:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor​
Click to expand...
Click to collapse
The command for setting awake_ideal_freq and sleep_ideal_freq are as follows:
echo 'FREQUENCY' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_ideal_freq
echo 'FREQUENCY' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
​
Now lets say we wanted to leave out awake ideal frequency at ROM default of 800 MHz, but wanted to make the sleep ideal frequency higher, to 368 MHz from 245 mHz. We could do it two ways.
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '400000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq​
Click to expand...
Click to collapse
You could also put the exact frequency:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '368640' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq​
Click to expand...
Click to collapse
Both will have the same effect.
TAKE NOTE OF THE ORDER, YOU MUST ENABLE SMARTASS FIRST, BEFORE TWEAKING ITS SETTINGS SO PUT THE LINE TO ENABLE SMARTASSV2 BEFORE THE CODES TWEAKING IT
Okay, lets move on to CPU load.

Understanding max and min cpu load
In the previous part of this guide we learned who to set the ideal wake and sleep levels.
Lets move on to another pair of important tunables:
max_cpu_load
min_cpu_load
max/min cpu load is set at a % figure.
For if example max_cpu_load is set at "55", than when the average processor usage is over 55% for a given period of time the processor will speed up. min_cpu_load is the figure that governs when the processor will slow down.
Before talking about how to do this, lets do that math since these two figures have to be set in a mathematically correct way.
A lot of popular ROM's these days have very few choices in terms of clock speeds:
122 MHz
245 MHz
368 MHz
768 MHz
806 MHz
1024 MHz
and so on.​
Click to expand...
Click to collapse
These are the clock speeds on the Blackout ICS ROM and other ROM's based on the Virtuous Kernel. You can find the available clock speeds for a ROM by looking at the sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies. In that file you will see clockspeeds in Hertz rather than MHz so 122000 = 122 mHz.
The Blackoyr ROM also sets:
max_cpu_load = 55
min_cpu_load = 25
ramp_up_step = 200000
ramp_down_step = 300000
Click to expand...
Click to collapse
Ramp up and ramp down steps are also important to how this all works, and can be adjusted, but lets leave that to the next part of this guide.
Slowing down
Using the setting in the Blackout ROM, this is how min_cpu_load works
Okay, all this is a bit confusing (or at least I am having a hard time writing it) but let me see if I can explain it by example. Lets says you just completed a heavy task and the phone is running at full speed (1024 MHz be default). The phone will continue to run at this speed, until the average processor use is below min_cpu_load:
1024 x 0.25 = 256 MHz​
Click to expand...
Click to collapse
So the processor goes down from 1024 MHz by 300 MHz (the ramp down speed) to 768 MHz. If processor use goes to below 256 MHz, the processor will ramp down to 768 MHz.
One at 768 MHz, the governor will compute again:
768 x 0.25 = 192 MHz​
Click to expand...
Click to collapse
If the average processor speed is less than 192 MHz, is will continue to slow down. If greater than 192 MHz it will stay at 768 MHz.
Speeding up
With the phone now running 768 MHz, if the load goes higher the max_cpu_load than the processor will speed up. At 768 MHz the max_cpu_load is 422 MHz:
768 x 0.55 = 422 MHz
Click to expand...
Click to collapse
Logical values
When setting this two figures, it is important that:
cpu frequency x cpu_min_load for the higher speed
BE HIGHER THAN
cpu frequency x x cpu_max_load for the lower speed
Click to expand...
Click to collapse
Lets say we set:
max_cpu_load = 55
min_cpu_load = 45​
Click to expand...
Click to collapse
Using the the new figures, we just completed another heavy task and the phone is again running at full speed (1024 MHz be default). The phone will continue to run at this speed, until the average processor use is below min_cpu_load:
1024 x 0.45 = 461 MHz​
Click to expand...
Click to collapse
Lets say the average processor speed is at 450 MHz, so the processor scales down to 768 MHz.
If processor use remain continues at 450 MHz, the governor will compute again:
768 x 0.45 = 345 MHz​
Click to expand...
Click to collapse
Since 400 MHz is higher than 345 MHz. The processor stays at 768MHz and the governor stops ramping down. But the governor is also checking if it should speed up:
768 x 0.55 = 422 MHz​
Click to expand...
Click to collapse
Since average speed is over 422 MHz, the processor speeds up back to 1024 MHz. And when there, it will ramps down again.
In sum:
max_cpu_load = 55
min_cpu_load = 45
Are not good values when use with a ROM where the available frequencies are far apart like the ones on the Blackout ROM. The min_cpu_load it too close to max_cpu_load.
Before we set the max_cpu_load and min_cpu_load in our current project, we should also discuss ramp_up and ramp_down steps.

Setting max_cpu_load, min_cpu_load, ramp_up_step and ramp_down_step.
Previous post was on setting cpu thresholds.
Lets go back to our previous example:
CPU Frequencies:
122 MHz
245 MHz
368 MHz
768 MHz
806 MHz
1024 MHz
max_cpu_load = 55
min_cpu_load = 25
ramp_up_step = 200000
ramp_down_step = 300000​
Click to expand...
Click to collapse
Ramp up
Starting at 245 MHz, with these settings when the CPU use hits greater than 55%, the processor will ramp up 200000 Hz or 200 MHz.
From 245 MHz to 445 MHz. Since there is no 445 MHz setting, it will go to the closest which is 368 MHz.
From 368 MHz it will ramp up to 568 MHz. There being no 568 MHz frequency it will go to 768 MHz.
From 768 MHz it will ramp up to 968 MHz. There being no 986 MHz frequency it will go to 1024 MHz.
Click to expand...
Click to collapse
Ramp down
Starting at 1024 MHz, with these settings, when the CPU use goes below 25%, the processor will ramp down 300000 Hz or 300 MHz.
From 1024 MHz to 768 MHz.
From 768 MHz it will ramp up to 368 MHz.
From 368 MHz it will ramp up to 245 MHz.
Click to expand...
Click to collapse
In computing you max_cpu_load and min_cpu_load, you should consider the settings to determine which speeds you should use to calculate:
cpu frequency x cpu_min_load for the higher speed
BE HIGHER THAN
cpu frequency x x cpu_max_load for the lower speed​
Click to expand...
Click to collapse
Commands to set max_cpu_load, min_cpu_load, ramp_up_step and ramp_down_step.
The commands are:
echo '%' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo '%' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo 'HERTZ' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo 'HERTZ' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
Going back to our current project the settings could look like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '400000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
echo '75' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo '30' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo '150000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo '200000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step​
Click to expand...
Click to collapse
Next lets us go to up_rate_us and down_rate_us.

up_rate_us/down_rate_us
The up_rate_us setting dictates how much time the phone will stay at a frequency before ramping up. It only applies after reaching the awake ideal frequency when the screen is on, and the sleep ideal frequency when the screen is off.
To understand this better, let us assume the following settings:
CPU Frequency: 245 MHz to 1200 MHz
Available Frequencies: 245 > 368 > 806 > 1024 > 1200 MHz
Awake ideal frequency: 1024 MHz
Sleep ideal frequency: 368 MHz
Max CPU Load: 60%
Min CPU Load: 25%​
Click to expand...
Click to collapse
If the processor is running a 245 MHz, and detects a load it will go from 245 MHz to 368 MHz to 768 MHz to 1024 MHz as soon as CPU load hits 60%. When it hits the awake ideal frequency of 1024 MHz it will not go up to 1200 MHz even if the CPU usage hits 60% unless it has spent as least X number of microseconds at 1024 mHz. This X number of seconds is the up_rate_us setting.
up_rate_us is set in microseconds. For example if, up_rate_us is set at 48000 (48,000 microseconds = 0.048 seconds).
In our example, the up_rate_us setting keeps the phone at 1024 MHz for at least 0.048 seconds before ramping up to 1200 MHz. The higher the setting, the more conservative the processors behavior will be.
down_rate_us works in the same way, but it reverse. If forces the cpu to stay at a frequency for a given number of milliseconds before ramping down WHEN BELOW THE IDEAL FREQUENCY.
Given out example. With the CPU at 1200 mHz. Once CPU use hits 25%, it will ramp down immediately. Once it hits 1024 mHz or lower, it will ramp down only after it has spent as least X number of microseconds at a frequency. The lower the down_rate_us setting, the more conservative the processors behavior will be.
Command to set up_rate_us/down_rate_us
echo 'MICROSECONDS' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_rate_us
echo 'MICROSECONDS' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/down_rate_us
I have not spent much time experimenting with these settings.

thanks for your good work:
but it's seem you are wrong when mentioned: "You will find the smartassV2 settings in /sys/devices/system/cpu/cpu0/cpufreq/smartass"
actually its locaton will be /sys/devices/system/cpu/cpufreq/smartass
another question is what's about value : /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
mind it sets to 9999999, very strange
So, I made this script
68ioshcedinit:
Code:
#!/system/bin/sh
# - sysctl -p
echo "noop" > /sys/block/mmcblk0/queue/scheduler;
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
echo '245760' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
echo '245760' > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo '768000' > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo '806400' > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq;
echo '55' > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo '30' > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo '200000' > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo '300000' > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;

Sorry, cpu0 is a typo. A bit too much cut and paste on my part.
9999999 basically tells it to ignore that setting. If you place a valid frequency in that setting, the processor will jump to that speed when you wake the phone.
Sent from my Desire HD using xda premium

Thanks a lot for this guide. I didn't want an app to control my kernel as it feels like it slows the phone down (maybe placebo) I made a script to set my Gov, CPU max/min and I UV all of my CPU freq all worked perfect. I didn't make a .zip I just made the file and copied into the init d folder and set permissions. One thing I did do wrong though was I didn't convert the file so it didn't work, I found this in another guide ''Edit-->EOL Conversion-->UNIX/OSX Format'' when I started notepad ++ it wasn't automatically set to this. Hope this helps someone and thanks a lot for this, now I just need to decide if I was a custom MM ROM or stock MM with xposed

[ROOT][OP5T] Remove OnePlus 5T Cluster 2 2361Mhz Frequency Cap

Overclocking
OnePlus 5T A5010
This is an overclock solution for the clock speed
limiter on the OnePlus 5T's second cluster of CPUs.
Requires root access, and advised to make
a TWRP recovery backup before attempting this.
ElementalX Kernel Manager
Download
X-plore File manager
Download
(Or root browser of your choice)
Build.prop Editor
Download
SSD Boost
Download
1.
First, open up X-plore and navigate to
root/system/etc/vendor/perf/targetconfig.xml
Long press on targetconfig.xml and hit edit text,
then scroll to the very bottom where
you'll find the 2361Mhz limiter.
Replace the config1 brackets with this
Code:
<Config1>
<TargetInfo
Target="msm8998"
NumClusters="2"
TotalNumCores="8"
SocIds="292,319"
SynCore="1"
CoreCtlCpu="-1"
MinCoreOnline="0"
CpufreqGov="1" />
<ClustersInfo Id="0" NumCores="4" Type="little" />
<ClustersInfo Id="1" NumCores="4" Type="big" />
</Config1>
If you've already flashed ElementalX kernel
you can reboot and skip step 2.
2.
Flash the custom kernel
from the ElementalX tab in the app.
Choose custom installation and proceed
to select the overclock frequency caps in recovery.
3.
Set the max frequencies to 2035 and 2592Mhz
and tick the on boot icon blue.
Disable core_control and enable msm_thermal
tick both set on boot.
Enjoy your heightened and less restricted
CPU speeds.
See below for tuning
You should notice a considerable boost
in performance with these apps/tweaks.
Hope this helps anyone that's been having trouble.
Feel free to comment whether or not it worked for you.
Buy me a beer:
PayPal.me/newton3788​

ElementalX Tweaks
CPU Min/Max
Cluster 1: 518Mhz / 2.03Ghz
Cluster 2: 806Mhz / 2.59Ghz
CPU Boost
Core 0: 748Mhz / Core 4: 1.26Ghz
Duration: 100ms
GPU
GPU Boost: High
Interactive governor tunables
I've added the downloadable cluster profiles at the bottom.
You may place them in the ElementalX gov_profiles folder.
Cluster 1:
go_hispeed_load - 75
above_hispeed_delay - 20000 2035200:30000
timer_rate - 20000
hispeed_freq - 1670400
timer_slack - 50000
target_loads - 70 1804800:85 1900800:90
min_sample_time - 25000
Cluster 2:
go_hispeed_load - 85
above_hispeed_delay - 20000 2592000:50000
timer_rate - 20000
hispeed_freq - 2035200
timer_slack - 50000
target_loads - 80 2265600:85 2457600:90
min_sample_time - 25000
Build.prop Tweaks
ro.min.fling_velocity=6000
ro.max.fling_velocity=12000
persist.sys.composition.type=dyn
debug.composition.type=dyn
debug.egl.force_msaa=true
persist.sys.use_dithering=1
persist.sys.scrollingcache=1
profiler.force_disable_err_rpt=1
profiler.force_disable_ulog=1
ro.config.nocheckin=1
ro.kernel.android.checkjni=0
logcat.live=disable
wifi.supplicant_scan_interval=400
ro.media.enc.jpeg.quality=100
net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960
Open Xplore and edit
root/vendor/etc/build.prop
Replace and add these:
dalvik.vm.heapstartsize=32m
dalvik.vm.heapgrowthlimit=384m
dalvik.vm.heapsize=768m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=8m
dalvik.vm.heapmaxfree=16m
Developer Options
Force GPU Rendering off
Disable HW Overlays off
I've yet to find a solution for the random stuttering
But I'll add it if I do​

newton378 said:
ElementalX Tweaks
​
Click to expand...
Click to collapse
Thanks for your tips here mate.
can you tell how s battery life affected
after this changes,i m trying your settings
but i faced deep sleep problems,do you face this too?

broky said:
Thanks for your tips here mate.
can you tell how s battery life affected
after this changes,i m trying your settings
but i faced deep sleep problems,do you face this too?
Click to expand...
Click to collapse
My device sleeps fine, I use the greenify app to hibernate apps on screen off. I can't account for any tweaks you've made to your device apart from what I've detailed here, mine is stock OOS with the EX kernel. Battery life drops depending on usage but you don't overclock to save battery.
edit: I was having battery problems but I've since flashed stock OOS and set everything back up, the battery life is superb with these governor profiles.

OK,I was just anxious about deep sleep,
I know overclockung drains battery.
Will keep on trying this
EDITnewton378
why don t you post this on oneplus 5 thread also, so more people see it and test it?
(just a suggestion)

broky said:
OK,I was just anxious about deep sleep,
I know overclockung drains battery.
Will keep on trying this
EDITnewton378
why don t you post this on oneplus 5 thread also, so more people see it and test it?
(just a suggestion)
Click to expand...
Click to collapse
http://imgur.com/a/Bhqj83w
No problem with deep sleep on my end.

newton378 said:
http://imgur.com/a/Bhqj83w
No problem with deep sleep on my end.
Click to expand...
Click to collapse
were you using the phone for 2 hours constantly?
or you left the phone idle?

broky said:
were you using the phone for 2 hours constantly?
or you left the phone idle?
Click to expand...
Click to collapse
Constant use and then idle for 10 minutes, deep sleep initiated quickly. No idea what problem you're having, sorry.

newton378 said:
Constant use and then idle for 10 minutes, deep sleep initiated quickly. No idea what problem you're having, sorry.
Click to expand...
Click to collapse
Testing as we talking,till now my deep sleep is fine.
Probably something else caused this,thanks for your response and help.

Update

newton378 said:
ElementalX Tweaks
CPU Boost
Core 0: 748Mhz / Core 4: 1.26Ghz
Duration: 100ms
​
Click to expand...
Click to collapse
you mean
A
0:748Mhz
1:0
2:0
3:0
4:1.26Ghz
5:0
6:0
7:0
or
B
0:748Mhz
1:748Mhz
2:748Mhz
3:748Mhz
4:1.26Ghz
5:1.26Ghz
6:1.26Ghz
7:1.26Ghz
??
i use configuration B and the device is faster than ever but i need to know if this is right:good:

broky said:
you mean
A
0:748Mhz
1:0
2:0
3:0
4:1.26Ghz
5:0
6:0
7:0
or
B
0:748Mhz
1:748Mhz
2:748Mhz
3:748Mhz
4:1.26Ghz
5:1.26Ghz
6:1.26Ghz
7:1.26Ghz
??
i use configuration B and the device is faster than ever but i need to know if this is right:good:
Click to expand...
Click to collapse
I don't think it matters as each cluster's frequencies are locked in sync. Core 1-3 follow 0 and 5-7 follow 4. Setting SynCore to 0 in targetconfig.xml is supposed to allow all cores to fluctuate on their own but it doesn't. Controller must be embedded deeper in the system.

broky said:
OK,I was just anxious about deep sleep,
I know overclockung drains battery.
Will keep on trying this
EDITnewton378
why don t you post this on oneplus 5 thread also, so more people see it and test it?
(just a suggestion)
Click to expand...
Click to collapse
I believe the phone doesn't enter deep sleep when charging due to rapid charging technology. Not sure if turning the phone off to charge helps it stay low power.
I figure this because I left it charging overnight and I had 33 minutes deep sleep and 10 hours of min frequency.

is it required elementalx kernel?cuz i'm using arter kernel right now

filandry said:
is it required elementalx kernel?cuz i'm using arter kernel right now
Click to expand...
Click to collapse
For the tweaks in the second post, no. If you want to have the overclocked CPU speeds, it's made possible by flashing EX kernel with custom settings.
I've tried flashing bluspark kernel over EX kernel and the result was relatively smoother than stock OOS with only EX kernel, however a lot of the settings in EXKM were automatically reverting to bluspark defaults when changed. I don't advise flashing custom kernels over each other unless you want to experiment and have a backup.
You can still remove the limiter on the second cluster's cores with the targetconfig.xml tweak for 2.45Ghz max clock speed.

newton378 said:
For the tweaks in the second post, no. If you want to have the overclocked CPU speeds, it's made possible by flashing EX kernel with custom settings.
I've tried flashing bluspark kernel over EX kernel and the result was relatively smoother than stock OOS with only EX kernel, however a lot of the settings in EXKM were automatically reverting to bluspark defaults when changed. I don't advise flashing custom kernels over each other unless you want to experiment and have a backup.
You can still remove the limiter on the second cluster's cores with the targetconfig.xml tweak for 2.45Ghz max clock speed.
Click to expand...
Click to collapse
so i only need this right?(for remove limiter)
First, open up X-plore and navigate to
root/system/etc/vendor/perf/targetconfig.xml
Long press on targetconfig.xml and hit edit text,
then scroll to the very bottom where
you'll find the 2361Mhz limiter.
Replace the config1 brackets with this

filandry said:
so i only need this right?(for remove limiter)
First, open up X-plore and navigate to
root/system/etc/vendor/perf/targetconfig.xml
Long press on targetconfig.xml and hit edit text,
then scroll to the very bottom where
you'll find the 2361Mhz limiter.
Replace the config1 brackets with this
Click to expand...
Click to collapse
Correct.

newton378 said:
Correct.
Click to expand...
Click to collapse
okay,will give it try :good:
edit :
yes it worked,although it's litte bit different from your guide..
here's my guide to remove second cluster cpu clock limiter (no overclock) using stock cpu clock speed :
First, open up Explorer and navigate to
/system/vendor/etc/perf
Find and Long press on targetconfig.xml and hit edit text,
then scroll to the very bottom where
you'll find the 2361600 limiter number and change it to 2467600
Save And Exit,and then reboot the devices

filandry said:
okay,will give it try :good:
edit :
yes it worked,although it's litte bit different from your guide..
here's my guide to remove second cluster cpu clock limiter (no overclock) using stock cpu clock speed :
First, open up Explorer and navigate to
/system/vendor/etc/perf
Find and Long press on targetconfig.xml and hit edit text,
then scroll to the very bottom where
you'll find the 2361600 limiter number and change it to 2467600
Save And Exit,and then reboot the devices
Click to expand...
Click to collapse
Yes, that would effectively raise the frequency cap but it works the same removing it altogether. Hence, cluster 1 doesn't have the max freq parameter in there and it can hit 1.9Ghz by default.

a10
does it work for android 10