Okay guys, I made some kernel tweaks that work on any ROM, and on the ROMs I have tried, improve battery life/performance.
THE BATTERY SAVER SCRIPT WILL NOT IMPROVE QUADRANT SCORES!
THIS SCRIPT WILL BE UPDATED FREQUENTLY!
Last update 7/11
Latest update notes: Focused more on battery life.
Battery stats on Liquid Smooth 1.5 with script:
{
"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"
}
Prerequisites:
Have root access
An app that can run scripts on boot, like Script Manger, located here:
https://play.google....ptmanager&hl=en
INSTRUCTIONS:
If using Script Manager:
1. Navigate to file.
2.Open as Script/Executable.
3.Set it to run at boot and as SU.
4.Save
5. Reboot.
If using ROM Toolbox:
1. Select "Scripter"
2.Select new script
3. Copy and paste script into Scripter
4. Select "At Boot"
5. Reboot
Make it Last script:
Code:
#!/system/bin/sh
echo "500,512000,64,2048" > /proc/sys/kernel/sem
echo "3072" > /proc/sys/kernel/msgmni
echo "74000" > /proc/sys/kernel/msgmax
echo "3072" > /proc/sys/kernel/shmmni
echo "2268435456" > /proc/sys/kernel/shmmax
echo "16777216" > /proc/sys/kernel/shmall
echo "400000" > /proc/sys/kernel/sched_min_granularity_ns
echo "256" > /proc/sys/kernel/random/write_wakeup_threshold
echo "256" > /proc/sys/kernel/random/read_wakeup_threshold
echo "5" > /proc/sys/kernel/panic
echo "575810" > /proc/sys/kernel/threads-max
echo "1" > /proc/sys/kernel/panic_on_oops
echo "25" > /proc/sys/kernel/hung_task_timeout_secs
echo "600000" > /proc/sys/kernel/sched_latency_ns
echo "2000000" > /proc/sys/kernel/sched_wakeup_granularity_ns
echo "1" > /proc/sys/kernel/sched_compat_yield
echo "0" > /proc/sys/kernel/sched_child_runs_first
echo "0" > /proc/sys/kernel/hung_task_timeout_secs
echo "0" > /proc/sys/vm/oom_kill_allocating_task
#end of /kernel , start of /fs
echo "10240" > /proc/sys/fs/inotify/max_user_watches
echo "256" > /proc/sys/fs/inotify/max_user_instances
echo "32000" > /proc/sys/fs/inotify/max_queued_events
echo "15" > /proc/sys/fs/lease-break-time
echo "165164" > /proc/sys/fs/file-max
echo "1053696" > /proc/sys/fs/nr_open
#end of /fs, start of /vm
echo "0" > /proc/sys/vm/oom_kill_allocating_task
echo "4" > /proc/sys/vm/min_free_order_shift
echo "1" > /proc/sys/vm/overcommit_memory
echo "2" > /proc/sys/vm/panic_on_oom
echo "8" > /proc/sys/vm/page-cluster
echo "3" > /proc/sys/vm/drop_caches
echo "0" > /proc/sys/vm/oom_kill_allocating_task
echo "2048" > /proc/sys/vm/min_free_kbytes
echo "20" > /proc/sys/vm/vfs_cache_pressure
echo "80" > /proc/sys/vm/dirty_background_ratio
echo "90" > /proc/sys/vm/dirty_ratio
echo "3700" > /proc/sys/vm/dirty_writeback_centisecs
echo "2100" > /proc/sys/vm/dirty_expire_centisecs
echo "0" > /proc/sys/vm/laptop_mode
echo "0" > /proc/sys/vm/block_dump
echo "0" > /proc/sys/vm/swappiness
IF THESE SCRIPTS DON'T WORK, USE THIS ONE.
Find them HERE
STEP 1. Under File, select DOWNLOAD.
STEP 2. Find a way to get it to your phone,make sure it's not opened in any text editors, until it's on your phone.
STEP 3. Follow other instructions
All credit ofr the above script goes to housas08
Latest update notes: enabled ZRAM(compressed RAM), loads SIO I/O if available, also loads the hotplugx governor and SIO on boot. Ups read and write speeds all around, file system speedups, enables multi threading, tweaks to the hotplug and hotplugx governor, and more. You might get random reboots using this script, you might only get a coupke and then they will stop or they'll never stop. Inform me if you consistent random reboots.
Credit to zepelinrox for minfreee and adj valueshttp://forum.xda-developers.com/showthread.php?t=991276
Credit to whirleyes for theKernel Modules.
GET THE SIO I/O SCHEDULER AND THE HOTPLUGX GOVERNOR HERE!
I HIGHLY RECOMMEND THEM FOR PERFORMANCE!
Speed it UP! script:
Code:
#!/system/bin/sh
# Load SIO I/O and hotplugx governor
insmod /system/lib/modules/cpufreq_hotplugX.ko
insmod /system/lib/modules/sio-iosched.ko
echo "700000" > /proc/sys/kernel/sched_latency_ns
echo "300000" > /proc/sys/kernel/sched_min_granularity_ns
echo "26188" > /proc/sys/kernel/sched_features
#writes more pages to disc, when given oppurtunity
echo "8" > /proc/sys/vm/page-cluster
#drop all cahces when given oppurtunity
echo "3" > /proc/sys/vm/drop_caches
#Keep 4MB in memory
echo "4096" > /proc/sys/vm/min_free_kbytes
#Dump Vfs cache less
echo "20" > /proc/sys/vm/vfs_cache_pressure
echo "80" > /proc/sys/vm/dirty_background_ratio
#How much dirty data there must be to write to disc
echo "90" > /proc/sys/vm/dirty_ratio
#How often writeback daemons wakeup to write data to disc.
echo "900" > /proc/sys/vm/dirty_writeback_centisecs
#How old 'dirty" data has to be to be written to disc
echo "800" > /proc/sys/vm/dirty_expire_centisecs
#^^^^^^Both expressed in 100th of second^^^^^^
echo "20" > /proc/sys/vm/swappiness
#faster sdcard read speed
echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
#enable multi threading
echo "1" > /proc/sys/kernel/multi_threading
# file system speedups
mount -o remount,noauto_da_alloc /system /system
mount -o remount,noauto_da_alloc /data /data
mount -o remount,noauto_da_alloc /cache /cache
# disable logcat - performance boost & save memory,comment, reboot for logcat.
rm /dev/log/main
#sets cpu governor to hotplug, is most intelligent
echo "hotplug" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "950" > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
#decreases sampling rate, stops lag and saves battery
echo "500000" > /sys/devices/system/cpu/cpufreq/hotplug/sampling_rate
echo "75" > /sys/devices/system/cpu/cpufreq/hotplug/up_threshold
echo "45" > /sys/devices/system/cpu/cpufreq/hotplug/down_threshold
echo "15" > /sys/devices/system/cpu/cpufreq/hotplug/hotplug_out_sampling_periods
echo "5" > /sys/devices/system/cpu/cpufreq/hotplug/hotplug_in_sampling_periods
#sets I/O scheduler to SIO, considered best
echo "sio" > /sys/block/mmcblk0/queue/scheduler
echo "sio" > /sys/block/mmcblk1/queue/scheduler
#Sets read and write on I/O sceduler to max.
echo "2048" > /sys/block/mmcblk0/queue/read_ahead_kb
echo "2048" > /sys/block/mmcblk1/queue/read_ahead_kb
#will merge tasks if able
echo "1" > /sys/block/mmcblk0/queue/nomerges
echo "1" > /sys/block/mmcblk1/queue/nomerges
echo "1" > /sys/block/mmcblk0/queue/low_latency
echo "1" > /sys/block/mmcblk1/queue/low_latency
echo "256" > /sys/block/mmcblk0/queue/nr_requests
echo "256" > /sys/block/mmcblk1/queue/nr_requests
echo "2048" > /sys/block/mmcblk0/bdi/read_ahead_kb
echo "2048" > /sys/block/mmcblk1/bdi/read_ahead_kb
echo "256" > /sys/block/zram0/bdi
#cache cleaner
rm -r /cache/*.apk
rm -r /cache/*.tmp
rm -r /data/dalvik-cache/*.apk
rm -r /data/dalvik-cache/*.tmp
#doesn't verify bus info, faster I/O
echo "N" > /sys/bus/hid/drivers/motorola/module/parameters/mot_pass_through_mt_input
echo "256" > /sys/class/bdi/default/read_ahead_kb
#faster scroll speed
echo "64" > /sys/bus/hid/drivers/magicmouse/scroll_speed
#performance boost in read/write when heap is at 4MB.
echo "4096" > /sys/block/mmcblk0/queue/optimal_io_size
echo "4096" > /sys/block/mmcblk1/queue/optimal_io_size
#better memory mangement
echo "2048,4096,43008,47104,51456,55808" > /sys/module/lowmemorykiller/parameters/minfree
#OOM fixes , shoould see awesome increase in multitasking
echo "0,3,6,10,12,15" > /sys/module/lowmemorykiller/parameters/adj
#net speed tweaks
echo "0" > /proc/sys/net/ipv4/tcp_timestamps
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
echo "1" > /proc/sys/net/ipv4/tcp_sack
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
echo "1" > /proc/sys/net/ipv4/tcp_window_scaling
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes
echo "30" > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "404480" > /proc/sys/net/core/wmem_max
echo "404480" > /proc/sys/net/core/rmem_max
echo "256960" > /proc/sys/net/core/rmem_default
echo "256960" > /proc/sys/net/core/wmem_default
echo "4096,16384,404480" > /proc/sys/net/ipv4/tcp_wmem
echo "4096,87380,404480" > /proc/sys/net/ipv4/tcp_rmem
# Enable ZRAM compressed memory.
if [ -e /sys/block/zram0/disksize ] ; then
$LOG -p i "Enabling compressed RAM functionality (ZRAM)"
echo $((120*2048*2048)) > /sys/block/zram0/disksize
busybox mkswap /dev/block/zram0
busybox swapon /dev/block/zram0
fi
You will definitely see a boost in performance when running the following script.
For this to work, either run this code at boot with an app like ROM Toolbox.
Or run the attached file at boot with an app like Script Manager.
Thank you to PureMotive for the battery saving kernel tweaks to make compatible and tweak for this phone. and this thread by him
http://forum.xda-developers.com/showthread.php?t=1621808
If you can, please donate:
Donate!
Or at least leave me a thanks.
<<<<<<<<<<<<<<<
Enjoy!
Your link is broken
This can be added to my BootMenu boot script.
Do have any details on what each line improve??
maybe add comment before each line
whirleyes said:
Your link is broken
This can be added to my BootMenu boot script.
Do have any details on what each line improve??
maybe add comment before each line
Click to expand...
Click to collapse
I might comment this in the future, but I don't have the time right now. I'll fix the link to the forum in the morning, the script download is operational.
I'll suffice it to say that these tweaks make the kernel write to disc less, using less battery, but decreasing performance.
Sent from my DROID RAZR using XDA
So far: Running your script, CPU set to 800mhz max, felt no performance decrease. We'll see how this works in the future. Battery drain on EU kernel is terrible. I hope this helps a bit. Thank you!
dtrail1 said:
So far: Running your script, CPU set to 800mhz max, felt no performance decrease. We'll see how this works in the future. Battery drain on EU kernel is terrible. I hope this helps a bit. Thank you!
Click to expand...
Click to collapse
Yeah, us OG RAZR guts have to deal with crappy battery life. That's why I made this script, please post your findings.
Sent from my DROID RAZR using XDA
Can you make and update.zip that makes the script works?If this is possible ;s i'm a little newbie
luizfilipel said:
Can you make and update.zip that makes the script works?If this is possible ;s i'm a little newbie
Click to expand...
Click to collapse
Unfortunately, I don't have the skill to do so, if somebody with this skill would like to put together a flashable .zip, then I would be grateful.
Script updated, now has kernel tweaks for performance!
Enjoy!
sorry, a little question from noobs...
it should run both? or just pick one of it?
teradaz said:
sorry, a little question from noobs...
it should run both? or just pick one of it?
Click to expand...
Click to collapse
Just pick one, they contradict each other in values, so if you try to run both there will be issues in what gets applied.
Leviathan26 said:
Just pick one, they contradict each other in values, so if you try to run both there will be issues in what gets applied.
Click to expand...
Click to collapse
thank you...
doesn't work for me:
luizfilipel said:
Can you make and update.zip that makes the script works?If this is possible ;s i'm a little newbie
Click to expand...
Click to collapse
it would be useless, since you have to run the script each time you reboot your phone.
Turkishflavor said:
doesn't work for me:
Click to expand...
Click to collapse
Use the option in Script Manager to run on boot. Then reboot your phone. And the values will be applied.
sevenup30 said:
it would be useless, since you have to run the script each time you reboot your phone.
Click to expand...
Click to collapse
The updater script would probably look for an Init.d folder and run it from there on every boot, if it was there anyway.
Sent from my DROID RAZR using XDA
Leviathan26 said:
Yeah, us OG RAZR guts have to deal with crappy battery life. That's why I made this script, please post your findings.
Sent from my DROID RAZR using XDA
Click to expand...
Click to collapse
Some feedback: there are really improvements in battery life! Now I can rum the EU leak with 3G all the time and it doesn't eat the battery that much... No performancy decrease so far..
Gesendet von meinem XT910 mit Tapatalk 2
dtrail1 said:
Some feedback: there are really improvements in battery life! Now I can rum the EU leak with 3G all the time and it doesn't eat the battery that much... No performancy decrease so far..
Gesendet von meinem XT910 mit Tapatalk 2
Click to expand...
Click to collapse
Awesome! Can you take a screenshot so I can put it in the OP?
Leviathan26 said:
Awesome! Can you take a screenshot so I can put it in the OP?
Click to expand...
Click to collapse
But ive just charged it 3 hours ago and iam using it all the time. Screen on is 2 hours.
This is an older one without tweaks...
Gesendet von meinem XT910 mit Tapatalk 2
Your kernel tweaks, they are like governors? If so why is it not possible to have smartassv2 for example?
As well, did you started to work on this because of this?
Anyway, good job and I'll let you know about my experience with your tweaks =)
An1mA said:
Your kernel tweaks, they are like governors? If so why is it not possible to have smartassv2 for example?
As well, did you started to work on this because of this?
Anyway, good job and I'll let you know about my experience with your tweaks =)
Click to expand...
Click to collapse
Governors are different to tweak scripts. A governor drives the CPU directly to its needed configuration, speed on processes or things like that. This script makes the kernel working different on some processes.
---------- Post added at 12:05 AM ---------- Previous post was at 12:02 AM ----------
@OP: You added a second script. Can we run them both or better one of them alone?
dtrail1 said:
Governors are different to tweak scripts. A governor drives the CPU directly to its needed configuration, speed on processes or things like that. This script makes the kernel working different on some processes.
---------- Post added at 12:05 AM ---------- Previous post was at 12:02 AM ----------
@OP: You added a second script. Can we run them both or better one of them alone?
Click to expand...
Click to collapse
Just run one at a time, they contradict each other in values. And the performance script is going to be getting an update later today.
Make Your Own /init.d Script to do OC/UC, UV, and more....
I've seen a whole bunch of posts out there where users are hounding kernel devs about how to do this or that to their kernel using this or that app. The following is my take on these apps, why I do things the way I do, and how you can do them that way too.
disclaimer:
I am in NO way a developer or programmer. I've read some stuff and followed some directions. That's about it. I take no responsibility for your device releasing the magic smoke that makes it work or becoming otherwise non-functional.
Also....
Not all components in the examples provided will work with every kernel due to the fact every kernel dev incorporates different features. If you want to alter a parameter the dev hasn't specified in his sysfs, KINDLY ask him to provide it, but do NOT EXPECT him to. Things may be a certain way in his kernel for a reason. For these reasons, I make NO promise to the efficacy of any script upon any kernel.
Why apps are useful
Apps like Incredicontrol, setCPU, and CPU Master serve a purpose without a doubt. They're easy to use and, in some cases, are the only good way to manipulate your custom kernel. (Earlier incarnations of SebastianFM's kernel made CPU Master the best choice long-term.) They also make tweaking kernel settings quick and easy when you're experimenting.
Why apps suck
Apps aren't my first choice as a long-term solution. Though these apps aren't big, they are apps and that means they take up memory, clock cycles, and battery power to run. That's why I prefer to make a script to do what most of these apps do.
An /init.d script is basically a list of commands that the system executes at boot or when commanded to, and it does these things with the least amount of burden on the system as possible. This makes /init.d scripts ideal, if not the only option, for performing certain functions. For the purpose of this thread, I'm going to stick to the basics of what most of the CPU tweaking apps do.
The Meat and Potatos
First, lets look at a script.
Code:
#!/system/bin/sh
echo 30 > /proc/sys/vm/swappiness
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 30 > /proc/sys/vm/vfs_cache_pressure
echo 3074 > /sys/block/mmcblk0/queue/read_ahead_kb
AWAKE_GOVERNOR="smartassV2"
AWAKE_GOVERNOR_FREQENCY_MAX="1782000"
AWAKE_GOVERNOR_FREQENCY_MIN="384000"
AWAKE_GOVERNOR_UP_RATE_US="40000"
AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ="540000"
AWAKE_GOVERNOR_MAX_CPU_LOAD="80"
SLEEP_GOVERNOR="ondemand"
SLEEP_GOVERNOR_FREQENCY_MAX="486000"
SLEEP_GOVERNOR_FREQENCY_MIN="192000"
SLEEP_GOVERNOR_POWERSAVE_BIAS="20"
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo $AWAKE_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $AWAKE_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $AWAKE_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $AWAKE_GOVERNOR_UP_RATE_US > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo $AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq
echo $AWAKE_GOVERNOR_MAX_CPU_LOAD > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load
AWAKE=
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
echo $SLEEP_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $SLEEP_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $SLEEP_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $SLEEP_GOVERNOR_POWERSAVE_BIAS > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
SLEEPING=
fi
done &)
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
sysfile="/sys/devices/system/cpu/cpu1/cpufreq/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile
What you're looking at...
The first 4 lines have nothing at all to do with your CPU. "/swappiness" and "/vfs_cache_pressure" have to do with the system's tendency to create a swap file or cache your file system. "/scheduler" sets the I/O scheduler. And "/read_ahead_kb" tells the system how far to read ahead on mass storage. Mass storage should be understood as the primary storage location of system data and apps on the device, NOT your SD Card. Those settings are elsewhere and your ROM dev may have an /init.d script called "01tweaks" that covers those. I couldn't begin to explain all of the settings within a Linux/Android kernel that can be tweaked/modified to good or bad effect.
To explain what going on next...
The next 2 groups of lines,
"AWAKE_GOVERNOR="smartassV2" specifies the smartassV2 gov for the "awake" state
AWAKE_GOVERNOR_FREQENCY_MAX="1782000" specifies the max frequency
AWAKE_GOVERNOR_FREQENCY_MIN="384000" specifies the min frequency
AWAKE_GOVERNOR_UP_RATE_US="40000" This value is the minimum step up the governor will make in ramping up frequency
AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ="540000" This is the target freqency the governor will attempt to attain
AWAKE_GOVERNOR_MAX_CPU_LOAD="80" This is the % load at which point the governor will begin ramping up frequency
SLEEP_GOVERNOR="ondemand" specifies the ondemand governor for "sleep" state
SLEEP_GOVERNOR_FREQENCY_MAX="486000" set the max frequency
SLEEP_GOVERNOR_FREQENCY_MIN="192000" sets the min frequency
SLEEP_GOVERNOR_POWERSAVE_BIAS="20" specifies the powersave bias, which is specific to the ondemand governor
These values are applied here:
"(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo $AWAKE_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $AWAKE_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $AWAKE_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $AWAKE_GOVERNOR_UP_RATE_US > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo $AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq
echo $AWAKE_GOVERNOR_MAX_CPU_LOAD > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load
AWAKE=
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
echo $SLEEP_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $SLEEP_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $SLEEP_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $SLEEP_GOVERNOR_POWERSAVE_BIAS > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
SLEEPING=
fi
done &)
If you're kernel doesn't support different awake and sleep profiles, or you don't want to do them, then that's a lot of pointless typing. It's easier to just do this:
Code:
echo 384000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1782000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo smartassV2 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 40000 > /sys/devices/system/cpu/cpufreq/smartassV2/up_rate_us
echo 540000 > /sys/devices/system/cpu/cpufreq/smartassV2/awake_ideal_freq
echo 80 > /sys/devices/system/cpu/cpufreq/smartassV2/max_cpu_load
(This may be the method of choice for all HTC source kernels in order to avoid issues.)
For most of you this will accomplish your goals. SmartassV2, as well as several other governors, recognize "awake" and "sleep" and adjust themselves accordingly so setting up profiles isn't all that necessary.
This here is where your voltages are set for each frequency stepping your kernel provides. This is the equivalent of typing out "echo "192000 775000" > sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" for every stepping.
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile
Let the mayhem begins....
Now that you've got yourself a script that will do what you want, lets talk about what to do with it.
First, I highly suggest you do NOT whip up a script like this and push it off to your device willy nilly. Once it's out there it's going to execute at boot, every time, without fail. If you've specified voltages or frequency settings that aren't stable, your device will become unstable before you can do anything about it. You're only easy fix at that point is restore from a backup, or reflash your ROM and kernel. Instead, what I recommend is that you experiment with your settings, either through an app (whether it retains the settings after reboot or not), or bust out ADB or a terminal emulator and run the settings you intend to apply. In the event your device goes wonky and restarts, whatever you've entered is lost and default parameters take effect.
Second, you're going to want to use a Linux native text editor to create this thing. I use Vim on my computer or any number of text editors on my device. Pretty much all text editors on Android will work. Windows/Microsoft editors don't format the text correctly and Linux doesn't like the file extensions. In short, it won't work even if it LOOKS right.
Assuming your script settings are stable, you're ready push it to your device and apply it.
Crack open your ADB shell and enter the following:
Code:
adb push [I]filenamehere[/I] /system/etc/init.d
Then open your shell:
Code:
adb shell
Now to set the file's permissions:
Code:
su
chmod 755 /system/etc/init.d/[I]filenamehere[/I]
And now you can execute it just as it would be if you rebooted your device:
Code:
sh /system/etc/init.d/[I]filenamehere[/I]
Alternative Execution
Install ScriptManager, place your script somewhere you can find it, set it to have SU privileges and to "run at boot", and profit.
Problems???
If you execute the script and you see a bunch of jazz come up LIKE "blahblah/blah/blahblah/blah: no path or directory exists" there's a good chance you fat-fingered something. It's also possible you're using a kernel that doesn't support whatever you're trying to do. Just because a kernel has a given governor does not mean that the sysfs (the mechanism that allows your script to set parameters) allows for the governor itself to be tweaked. The same applies for any parameter. That will also generate error messages as described above.
If you attempt to push your script to your device via ADB and it fails to allow you to do this, make sure your /system is mounter R/W as in Read/Write, as opposed to R/O as in Read/Only.
I'm happy to answer questions, but I warn you now, I don't know a whole lot. The primary purpose of this guide is to provide a better way to do what CPU tweaking apps do, not teach the finer points of script creation... which I couldn't teach anyone if I wanted to because I don't know them myself.
Further Reading:
I'll add to this if/when I come across something relevant.
http://www.linuxinsight.com/proc_filesystem.html A well written guide to exploring and understanding the /proc directory in Linux.
Asides:
This is the script I'm currently using on SebastianFM's OC Kernel v. 1.4.0. Unless you want profiles and GPU overclocking, you don't need no stinking app. (Updated. Every line of this works and it's SMOOTH.)
Code:
#!/system/bin/sh
echo 30 > /proc/sys/vm/swappiness
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 60 > /proc/sys/vm/vfs_cache_pressure
echo 3074 > /sys/block/mmcblk0/queue/read_ahead_kb
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1728000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 30000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo 1512000 > /sys/devices/system/cpu/cpufreq/ondemand/two_phase_freq
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
sysfile="/sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile
This guide looks sweet. I saw your post in dsbs kernel thread and I was gonna try it when I got some free time and now I have a guide to help me out
Good stuff man
Sent from the Rez
Thank you for the script, had just pushed it to my Rez.
richii0207 said:
Thank you for the script, had just pushed it to my Rez.
Click to expand...
Click to collapse
Lemme know how it works out.
It doesn't look like your script is setting voltages for cpu1 (only cpu0), what am I missing?
gr8nole said:
It doesn't look like your script is setting voltages for cpu1 (only cpu0), what am I missing?
Click to expand...
Click to collapse
From what I understand, CPU1 gets reset when it goes offline, so setting any values is almost pointless. :/
Sent from my ADR6425LVW using Tapatalk 2
An explanation of I/O Schedulers
An I/O scheduler can use the following techniques to improve performance:
Request merging - The scheduler merges adjacent requests together to reduce disk seeking
Elevator - The scheduler orders requests based on their physical location on the block device, and it basically tries to seek in one direction as much as possible.
Prioritisation - The scheduler has complete control over how it prioritises requests, and can do so in a number of ways
No-op Scheduler:
This scheduler only implements request merging.
Anticipatory:
The anticipatory scheduler is the default scheduler in older 2.6 kernels – if you've not specified one, this is the one that will be loaded. It implements request merging, a one-way elevator, read and write request batching, and attempts some anticipatory reads by holding off a bit after a read batch if it thinks a user is going to ask for more data.
Deadline:
The deadline scheduler implements request merging, a one-way elevator, and imposes a deadline on all operations to prevent resource starvation.
Complete Fair Queueing Scheduler (CFQ):
The complete fair queueing scheduler implements both request merging and the elevator, and attempts to give all users of a particular device the same number of IO requests over a particular time interval. The CFQ scheduler aims to distribute disk time fairly amongst processes competing for access to the disk. In addition, it uses anticipation and deadlines to improve performance, and attempt to bound latency.
Budget Fair Queuing (BFQ):
The Budget Fair Queueing (BFQ) scheduler turns the CFQ Round-Robin scheduling policy of time slices into a fair queueing scheduling of sector budgets.
SIO:
SIO Scheduler is based on the deadline scheduler but it's more like a mix between no-op and deadline.
In other words, SIO is like a lighter version of deadline but it doesn't do any kind of sorting, so it's aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).
V(R):
V(R) is similar to, and based on, Linux's deadline I/O scheduler. It implements request deadlines which try to limit starvation, but provide no hard guarantee of request latency. It also merges and batches requests in a similar manner, but unlike deadline, read and write requests are issued together. This means there is no preference to reads over writes. Thus, higher throughput can be achieved at the cost of interactive performance.
credit: EducateandInnovate link: here
Great guide thanks