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.