Related
I was playing around with adjusting and monitoring the CPU rate on my A43, and I discovered an oddity. I have the device set to overdrive, so normally it can do 1ghz. But I noticed that inside Netflix's video player (not just the Netflix app, the video player), the CPU speed was only 800mhz and there was some stuttering. Looking more carefully, I noticed that somehow as soon as the video player started up, the maximum scaling frequency went down to 800mhz. Exit, and it goes back to 1ghz. I then found that the same happens in Youtube and the Archos Video player.
How annoying, though maybe there is some good reason for it? Is it perhaps that the video hardware can't handle the greater speed? Does anybody know?
Anyway, I have a simple fix: You just have to turn off the write permissions on /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after the values have been all set. I don't know if any of the CPU speed utilities like SetCPU let you do this.
I fix this by setting my CPU speed settings via a script that runs on boot. (I run it via a tiny utility I wrote which I am not presently releasing, but you could also run it via Script Manager.) The script I use is:
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo conservative > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
echo 300000 > scaling_min_freq
echo 150000 > conservative/sampling_rate
echo 70 > conservative/up_threshold
The crucial line is the "chmod 444 scaling_max_freq" which sets the scaling_max_freq file to read-only. (Of course, a determined app that wants to change it can just chmod 644 scaling_max_freq and write to it. But whatever is doing the switch 800mhz isn't THAT determined.)
The result is that Star Trek plays smoothly at 1ghz in Netflix, as it should, while the built-in video player when playing lower-resolution videos uses 800mhz, as it also should.
If you have a device with a higher top speed than 1000000, just change the 1000000 to whatever your top speed is.
If you want to check if your device has the issue, start up a video, and then while the video is playing, do:
Code:
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
If it's less than the top speed of your device, you have the issue.
But maybe it's supposed to be like that?
arpruss said:
The script I use is:
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo conservative > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
echo 300000 > scaling_min_freq
echo 150000 > conservative/sampling_rate
echo 70 > conservative/up_threshold
Click to expand...
Click to collapse
Would I run this script verbatim for interactive mode? Or change 'conservative' in the script to 'interactive'?
EDIT I think I get it...... gonna play for a bit....
I think the stock ROM only supports ondemand, conservative and performance.
arpruss said:
I think the stock ROM only supports ondemand, conservative and performance.
Click to expand...
Click to collapse
I'm on Uruk 1.0, err, well both, but I dominantly run on Uruk
wokker666 said:
I'm on Uruk 1.0, err, well both, but I dominantly run on Uruk
Click to expand...
Click to collapse
I see. Then, yes, you do need to change things to set up whatever settings you want for interactive. Are you using any CPU-setting utility? I don't know how well my script will work with a CPU-setting utility. The one I tried automatically set read/write permissions to the files, which undoes the effects of my script.
I think I got it
I can confirm that SetCPU does reset the permissions, killing SU permissions to the app seems to fix that
I remade the script to go a little something like...
Code:
cd /sys/devices/system/cpu/cpu0/cpufreq
echo interactive > scaling_governor
chmod 644 scaling_max_freq
echo 1000000 > scaling_max_freq
chmod 444 scaling_max_freq
chmod 644 scaling_min_freq
echo 600000 > scaling_min_freq
chmod 444 scaling_min_freq
The scaling_min_freq part may seem useless, but it further sets what you want in stone
So far after a few reboots, everything seems to be working just fine, and the system dosen't scale the cpu to 800000 when in video!
Nice!
Thanks!
Any idea WHY Archos did that 800mhz scaling?
Maybe it's just a bug. I think they initially wanted the device to run at 800MHz, and then later added an Overdrive mode at 1000. So the 800 could be a leftover, no?
arpruss said:
Any idea WHY Archos did that 800mhz scaling?
Maybe it's just a bug. I think they initially wanted the device to run at 800MHz, and then later added an Overdrive mode at 1000. So the 800 could be a leftover, no?
Click to expand...
Click to collapse
I think they did it to help conserve the battery, if you use your unit for mostly video, it would make sense to not burn through your battery at 1ghz...
On that note, my system with the settings I just made, in video it REALLY scales to my settings.... it dominantly runs at 600mhz, not 1ghz - maybe it's the interactive mode kicking in, it just dosent see the demand - I can't test in real time right now though, no linux machine as of yet, but time in state shows mostly 600mhz, and some 1ghz
wokker666 said:
I think they did it to help conserve the battery, if you use your unit for mostly video, it would make sense to not burn through your battery at 1ghz...
Click to expand...
Click to collapse
But that's what the scaling is for. When the video doesn't need the higher speed, it scales it down, and when it needs it, it scales it up. Star Trek on Netflix needs 1000, while different xvid videos that I have need different speeds.
By the way, I noticed that they also set scaling_min_freq to 800 in the video player. So, my script also needs a line:
Code:
chmod 444 scaling_min_freq
at the end.
arpruss said:
But that's what the scaling is for. When the video doesn't need the higher speed, it scales it down, and when it needs it, it scales it up. Star Trek on Netflix needs 1000, while different xvid videos that I have need different speeds.
Click to expand...
Click to collapse
Most of what I was testing are .mkv's of all sorts of flavors, they probably dont need to bump up the speed - I should find a hd vid to test with.
By the way, I noticed that they also set scaling_min_freq to 800 in the video player. So, my script also needs a line:
Code:
chmod 444 scaling_min_freq
at the end.
Click to expand...
Click to collapse
I knew I threw that in for a reason
It looks like the writing of the modified frequencies is done by /system/bin/powerd, and it's requested by /usr/bin/avos when the DSP is called for.
arpruss said:
It looks like the writing of the modified frequencies is done by /system/bin/powerd, and it's requested by /usr/bin/avos when the DSP is called for.
Click to expand...
Click to collapse
I wonder if this is something that can be manually changed, or maybe Sauron take a look at it and implement the changes in the next Uruk?
On another note, I gotta say, after locking down my cpu with this script, plus a few other settings in an app I have (autokiller memory optimizer), my system has never run better, very snappy!!!
Since our phone has little ram and many apps like running services we probably don't need in the background (youtube, google search, K9 mail/gmail for those of us checking emails manually), is there any way to optimize our phones by limiting the apps when it comes to services? I mean, is there any way to not let an app run a background service?
I tried freezing app autostarts with Autostarts, but I couldn't do it for some apps. I am also using FastReboot but I feel that it is only a workaround.
I keep feeling that my phone runs faster when it has 60+ free mb of RAM, but this is hard to accomplish. What do you guys think?
By the way, I also felt that Juwe RAM Script and the Sysctl config posted in the script's thread didn't do anything to my RAM.
--
Update @ Aug/21:
There's a script that works in all cellphones the same and it was created by zeppelinrox. Read about it here: http://forum.xda-developers.com/showthread.php?t=991276
For some reason, settings don't stick after reboot for us no matter what we do. This has been confirmed to happen in GingerDX and in MiniCM (confirmed by me) on CM7. We still don't know why
Alternatively, some users have suggested introducing the script in build.prop (read bellow). In my case, even without the values not sticking, my phone is smoother. You can try the following at your own risk:
This is some info that Pjay12 gathered from other posts:
Pjay12 said:
Here goes -
Credits to Zeppelinrox and alfsamsung
I tried to make this as noob-friendly as possible.
First steps - Run the script and reboot once (just in case) It will create a 99SuperCharger in init.d, deleting this is not necessary.
Uninstall/freeze AMM, AKMO, Minfree Manager, whatever else you have that can alter Minfree values.
This may differ with each rom but delete any other ramscript from etc/init.d
[On a standard GingerDX these are the files that should be in init.d
01sysctl
03firstboot
04modules
05mountsd
06gingerdx
06mountdl
10apps2sd
20userinit
99SuperCharger <-- after running the SuperCharger Script]
Changes -
1. system/etc/hw_config :
Add these lines to the bottom
# tweak launcher hard to kill from supercharger
echo "0,3,5,7,14,15" > /sys/module/lowmemorykiller/parameters/adj
echo "1536,2048,6656,7168,7680,8192" > /sys/module/lowmemorykiller/parameters/minfree
echo "0" > /proc/sys/kernel/panic
echo "0" > /proc/sys/vm/oom_kill_allocating_task
echo "0" > /proc/sys/vm/panic_on_oom
echo "1" > /proc/sys/kernel/panic_on_oops
echo "0" > /proc/sys/kernel/panic
The values in bold are my settings (Balanced 3 option in supercharger)
Values you will see are 6 ,8 ,26 ,28 ,30 ,32.
Change them to your desired values.
[Additional (how it works) - <value> * 4 / 1024 (<value/256)
Example - 1536/256 = 6, 8192*4/1024 = 32]
2. data/local.prop :
Make sure it looks like this-
ro.FOREGROUND_APP_ADJ=0
ro.VISIBLE_APP_ADJ=3
ro.PERCEPTIBLE_APP_ADJ=2
ro.HEAVY_WEIGHT_APP_ADJ=4
ro.SECONDARY_SERVER_ADJ=5
ro.BACKUP_APP_ADJ=6
ro.HOME_APP_ADJ=2
ro.HIDDEN_APP_MIN_ADJ=7
ro.EMPTY_APP_ADJ=15
ro.FOREGROUND_APP_MEM=1536
ro.VISIBLE_APP_MEM=2048
ro.PERCEPTIBLE_APP_MEM=1024
ro.HEAVY_WEIGHT_APP_MEM=6656
ro.SECONDARY_SERVER_MEM=6656
ro.BACKUP_APP_MEM=7168
ro.HOME_APP_MEM=1024
ro.HIDDEN_APP_MEM=7168
ro.EMPTY_APP_MEM=8192
Now reboot and check sys/module/lowmemorykiller/parameters/minfree (long press and select view as text) Your values should be what you put as the bold text in hw_config.
Click to expand...
Click to collapse
Pjay12 said:
--------------------------------------------------------------------------------------------------------------
OPTIONAL -
The following may or may not affect your phones performance. DO NOT rely on quadrants or any other benchmarks for performance. Its your own experience.
1. hw_config
Add these lines-
# we love fast sd speed
echo 512 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
# sysctl and ram tweak
echo "0" > /proc/sys/vm/swappiness
echo "2000" > /proc/sys/vm/dirty_writeback_centisecs
echo "1000" > /proc/sys/vm/dirty_expire_centisecs
echo "200" > /proc/sys/vm/vfs_cache_pressure
echo "80" > /proc/sys/vm/dirty_ratio
echo "40" > /proc/sys/vm/dirty_background_ratio
echo "0" > /proc/sys/vm/oom_kill_allocating_task
echo "2048" > /proc/sys/vm/min_free_kbytes
NOTE -
The above lines under "#sysctl and ram tweak" are alfsamsung's original tweaks.
If you haven't flashed kickasskernel, the below lines are editted with a few kickasskernels values (its what I use) If you want to try it, REPLACE the above lines under #sysctl and ram tweak with the lines below.
# sysctl and ram tweak
echo "0" > /proc/sys/vm/swappiness
echo "2000" > /proc/sys/vm/dirty_writeback_centisecs
echo "1000" > /proc/sys/vm/dirty_expire_centisecs
echo "20" > /proc/sys/vm/vfs_cache_pressure
echo "95" > /proc/sys/vm/dirty_ratio
echo "60" > /proc/sys/vm/dirty_background_ratio
echo "0" > /proc/sys/vm/oom_kill_allocating_task
echo "8192" > /proc/sys/vm/min_free_kbytes
2. system/build.prop
Add these lines to the bottom #wifi network etc..
rild.libpath=/system/lib/libril-qc-1.so
rild.libargs=-d
/dev/smd0
ro.ril.hsxpa=2
ro.ril.hsupa.category=5
ro.ril.enable.a52=1
ro.ril.enable.a53=1
ro.ril.def.agps.mode=2
ro.ril.gprsclass=12
ro.ril.def.agps.mode=2
ro.telephony.default_network=0
wifi.interface=wlan0
wifi.supplicant_scan_interval=90
#windows management
ro.sf.lcd_density=160
windowsmgr.max_events_per_sec=60
settings.display.autobacklight=1
settings.display.brightness=160
# The OpenGL ES API level that is natively supported by this device.
ro.opengles.version=131072
debug.sf.hw=1
# Tweaks
debug.sf.hw=1
ro.compcache.default=0
#media
ro.workaround.noautofocus=1
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
ro.media.dec.jpeg.memcap=10000000
ro.media.enc.file.format = 3gp,mp4
ro.media.enc.vid.codec = m4v,h263
ro.media.enc.vid.h263.width = 176,352
ro.media.enc.vid.h263.height = 144,288
ro.media.enc.vid.h263.bps = 64000,800000
ro.media.enc.vid.h263.fps = 1,30
ro.media.enc.vid.m4v.width = 176,352
ro.media.enc.vid.m4v.height = 144,288
ro.media.enc.vid.m4v.bps = 64000,800000
ro.media.enc.vid.m4v.fps = 1,30
# For SD storage insert notification sound
persist.service.mount.playsnd = 0
#dalvik options (more tweaks)
dalvik.vm.execution-mode=int:jit
dalvik.vm.heapsize=40m
dalvik.vm.dexopt-flags=m=y
#Other tweaks
mot.proximity.delay=400
When editting build.prop, you may have to make changes to both system/build.prop AND system/bin/build.prop
alfsamsung said:
- mot.proximity.delay=400 - sets the delay of screen on when using proximity sensor in calls (mseconds)
Click to expand...
Click to collapse
The important lines above are in bold. Make sure they are the same.
Reboot and check sys/module/lowmemorykiller/parameters/minfree. Values should be the same. If they aren't, feel free to PM. Hope it helps.
If it helps hit thanks for the respective contributors.
Enjoy.
Cheers.
Pjay
Click to expand...
Click to collapse
Dexter_prog said:
Since our phone has little ram and many apps like running services we probably don't need in the background (youtube, google search, K9 mail/gmail for those of us checking emails manually), is there any way to optimize our phones by limiting the apps when it comes to services? I mean, is there any way to not let an app run a background service?
I tried freezing app autostarts with Autostarts, but I couldn't do it for some apps. I am also using FastReboot but I feel that it is only a workaround.
I keep feeling that my phone runs faster when it has 60+ free mb of RAM, but this is hard to accomplish. What do you guys think?
By the way, I also felt that Juwe RAM Script and the Sysctl config posted in the script's thread didn't do anything to my RAM.
Click to expand...
Click to collapse
Same problem! Now I use Gingerdx 007 and i have the same problem i had with 006 and froyobread before that! My phone works like a charm, couldn`t be better! BUT....verry often it becomes so laggy and there is apsolutelly no way to fix it exept restart and it`s becoming really anoying. Sometimes i don`t use it for few hours and it simply "bricks" in my pocket! I can`t even answer if someone calls me. I know it has something to do with ram memory but nothing helps! Fast reboot makes it work for like 10 seconds and it`s stuck again. Advanced task killer kills apps in background and there they are again after couple of seconds. I`m not really sure that it will ever be fixed, whatever it is.
I dont have that problems, I reboot only when error comes up, or I battery drained.
Just uninstall those system apps..
Sent from my X8 using Tapatalk
woodpeckerlo said:
Same problem! Now I use Gingerdx 007 and i have the same problem i had with 006 and froyobread before that! My phone works like a charm, couldn`t be better! BUT....verry often it becomes so laggy and there is apsolutelly no way to fix it exept restart and it`s becoming really anoying. Sometimes i don`t use it for few hours and it simply "bricks" in my pocket! I can`t even answer if someone calls me. I know it has something to do with ram memory but nothing helps! Fast reboot makes it work for like 10 seconds and it`s stuck again. Advanced task killer kills apps in background and there they are again after couple of seconds. I`m not really sure that it will ever be fixed, whatever it is.
Click to expand...
Click to collapse
before gingerDx I was using Fast Reboot + automemory manager (set on aggressive or whatever the highest setting was) and it kind of did the trick. But it still seems that there's no way to beat a phone with low ram.
Just use Autokiller memory optimizer, and if you can, buy the donate version, so you can edit the upper settings. just set the 3 lower value to : 80,90,100
and if you have the donate version, just set the 3rd value to 60, and you'll have a fast system. but dont try to set the first and second value too high,
Dexter_prog said:
Since our phone has little ram and many apps like running services we probably don't need in the background (youtube, google search, K9 mail/gmail for those of us checking emails manually), is there any way to optimize our phones by limiting the apps when it comes to services? I mean, is there any way to not let an app run a background service?
I tried freezing app autostarts with Autostarts, but I couldn't do it for some apps. I am also using FastReboot but I feel that it is only a workaround.
I keep feeling that my phone runs faster when it has 60+ free mb of RAM, but this is hard to accomplish. What do you guys think?
By the way, I also felt that Juwe RAM Script and the Sysctl config posted in the script's thread didn't do anything to my RAM.
Click to expand...
Click to collapse
Juwe helps me. You have to put it in /etc/init.d and chmod 777 it. But i'm now using supercharger script, i think my phone is faster now.
Note: my signature has not been changed yet because i am now testing.
Try changing dirty ratio to 95 and dirty background ratio to 60 and vfs cache pressure to 10 and turn on OOM (not sure about this).
My minfrees are: 6,8,16,20,22,60
What's superchargerscript? Is it this one? http://forum.xda-developers.com/showthread.php?t=991276
I'm using the browser to browse Facebook and Twitter bcoz their app runs in background so I uninstalled them using Titanium Backup. And I have a little imprpvement.
Sent from my X8 using XDA App
The more the apps installed the more ram will be used. I dont know if it is possible to add ram but the only solution is to free some.
Dexter_prog said:
What's superchargerscript? Is it this one? http://forum.xda-developers.com/showthread.php?t=991276
Click to expand...
Click to collapse
Yeah. And i'm also using kernel tweaks by the same guy and turbo 3g. I'm testing them so quality assurance for x8 is not present yet.
@deedii in gdx my partition dont work it show memory card corrupted.........
i tried with cwc recovery to partition.....
can u help me??
#sorry for weak english
ithunter said:
@deedii in gdx my partition dont work it show memory card corrupted.........
i tried with cwc recovery to partition.....
can u help me??
#sorry for weak english
Click to expand...
Click to collapse
It should work as CWM partitions to ext 3. Set swap size to 0 and reboot your phone first to be sure that the sd card is really corrupted.
I partitioned with CWM and had no problems.
Only got lags when app needs more memory and system trying to kill background/stopped apps. That's really annoying, especially when IM gone sleep and was accidentally killed instead of some useless crap.
@ithunter oh im sorry sweetie but i dont use partition..
Using cwm partition ext sometime no work. i use minitool partition .
[email protected]
FroyoBread v024
|ax8smartass|x8mddi|x8gesture|
|x8uv|x8bootsound|Ext4|
|V6superchargerscript|Oc691mhz|
*Dont be shy ..if help click thank to me. 囧*
kakho55 said:
Using cwm partition ext sometime no work. i use minitool partition .
[email protected]
FroyoBread v024
|ax8smartass|x8mddi|x8gesture|
|x8uv|x8bootsound|Ext4|
|V6superchargerscript|Oc691mhz|
*Dont be shy ..if help click thank to me. 囧*
Click to expand...
Click to collapse
yes finally i use cwm partition with swip 0 size and it work better .... m happy
@deedii tyo to use it make little bit faster.....
actually i dont wanna tweak my phone a lot im satisfied with my settings right now.. thanks so much for the info btw
I heard bout this SuperCharger did someone already use this one? Hmm does it really boost our x8? hmm..
Here is the easiest way to install this script.
Install SuperCharger
btw how do you see version of busybox installed in your system? in gdx7? Sorry Im Noob.
deedii said:
I heard bout this SuperCharger did someone already use this one? Hmm does it really boost our x8? hmm..
Here is the easiest way to install this script.
Install SuperCharger
btw how do you see version of busybox installed in your system? in gdx7? Sorry Im Noob.
Click to expand...
Click to collapse
check with lsmod on terminal it may show... i am also noobs ^_^
deedii said:
I heard bout this SuperCharger did someone already use this one? Hmm does it really boost our x8? hmm..
Here is the easiest way to install this script.
Install SuperCharger
btw how do you see version of busybox installed in your system? in gdx7? Sorry Im Noob.
Click to expand...
Click to collapse
You can check busybox version by installing Busybox installer from the market
Hello everyone!
Does anyone knows if it exists a "tool" for undervolting or also if exist some vCore table that is working good giving a boost to the battery life?
It would be nice if someone posts some guide about
Thanks everyone
mrbr0wn said:
Hello everyone!
Does anyone knows if it exists a "tool" for undervolting or also if exist some vCore table that is working good giving a boost to the battery life?
It would be nice if someone posts some guide about
Thanks everyone
Click to expand...
Click to collapse
Of course there is a way
You can use SetCPU (paid app) or CPU Master (free ,search xda) and some more apps.
You can select the govenor of the kernel (smartass etc. ) and overvolt/overclock and undervolt your CPU if you have a kernel like tytung etc.
Battery boosting:
I just use smartass governor and undervolt a little bit ,which saves much energy.
#
Hope this is what you needed to know.
Uh?It sounds new to me! Really i can use SetCPU to undervolt? O.O
Yes.
If you set max frequenz to 800mhz, Kernel will just get up to that speed..
Sent from my HTC HD2 using XDA Premium App
...nope...i was talkin' about *undervolting*, not *underCLOCKING*...
mrbr0wn said:
...nope...i was talkin' about *undervolting*, not *underCLOCKING*...
Click to expand...
Click to collapse
Oh sry.
Was thinking you meant this.
Since I dont use this I cant help youy
Sent from my HTC HD2 using xda premium
No problem
Hope someone else can help me or suggest me the right way!
some builds are capable of being undervolted right from the start using a txt config file. I think DL desire has that.
Raf's new kernel also supports undervolting if I'm not wrong, but you have to do it manually. some CM7 roms can be undervolted manually as well.
I've never heard of an app that helps you do that, and I don't think one will be released soon with google trying to lock up every thing on android that more and more devices become unable to be rooted.
On Typhoon Cyanogen mod, I just edit the /system/etc/init.d/98cpuvoltage to my proven settings, and then flash the rom. According to Tyween, it's best to have 1 proven undervolt settings, and some extra for testing, so you won't make your phone un-usable.
To open a file, use Gscript lite, or terminal emulator, and type:
Sh /filepath/filename
Use a linux compatible text editor, like notepad++ to edit the settings.
My settings are this, but they might not work on your cpu.
Code:
#!/system/bin/sh
# set vdd_levels on boot by dorimanx (XDA Developers)
echo '245000 850' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '384000 875' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '422400 900' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '460800 925' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '499200 950' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '537600 950' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '576000 1000' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '614400 1025' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '652800 1050' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '691200 1075' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '729600 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '768000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '806400 1125' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '844800 1150' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '883200 1150' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '921600 1175' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '960000 1175' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '998400 1200' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1036800 1200' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1075200 1225' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1113600 1250' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1152000 1250' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1190400 1275' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
thanks everybody for the replies, i started to "study" the question before to see your msgs, i found the file in /etc/init.d/ and started to lower the vCores... the thing that really sounds strange to me is that i've taken another file from a forum (that should be already undervolted, even if only a bit), lowered again in the middle range freqs (like from 499200 to 1036800), stressed cpu, and never had a restart/freeze...it seems to me a little strange....it could means 3 things:
1- i'm not really changing the voltages (even if i can see my settings in /sys/devices/system..ecc)
2 - by default, the cpu works with too high voltages
3 - i own a VVEEEEEEERRRY lucky hd2 that can handle undervolting very well
(3bis - the program that i'm using to stress the cpu isn't working XD) [checked with top/htop, cpu load goes to 100% and stay here during the stress test, so it should be working good ]
does anyone knows a way to see the "live" cpu voltage as it happens with the clock? i mean, a way to see the cpu voltage in real time!
thanks
Maybe this is what your are looking for:
http://forum.xda-developers.com/showthread.php?t=1223639
Sent from my HTC HD2 using xda premium
just to update the post...
made some experiments....
245000: 850
384000: 850
422400: 875
460800: 875
499200: 875
537600: 900
576000: 950
614400: 975
652800: 975
691200: 1025
729600: 1025
768000: 1050
806400: 1075
844800: 1075
883200: 1100
921600: 1125
960000: 1150
998400: 1150
1036800: 1175
1075200: 1175
1113600: 1175
1152000: 1200
1190400: 1225
that seems to be the best vdd table that i can use...max undervolting, no strange reboot or similar...i have some random FC atm, but i'm not really shure that undervolting is causing this! i'll take a look and eventually, update again the post
I'm one of those persons that tests stuff all day long, from kernels, to custom made kernels, overclocking, benchmarks, roms and that stuff so I felt in the need of something that could provide me with CPU Temp and current CPU Frequency because I was testing governors and cpu throttling.
No, you don't need ROOT, you can do this on a 100% stock tablet.
What you need
USB Debugging enabled on your tablet.
ADB in your computer (if you don't have/know about this, you should find a manual )
How to do it
1) Connect your tablet to the computer (you can do this over usb or you can use adb wireless apps)
2) Open up a command shell (Windows users: CMD, Linux/Mac users: Terminal)
3) Type adb shell (Make sure you are in the folder where your adb program is located, if you have setup System Variables you can skip that)
4) Your terminal/cmd should say something like this now: [email protected] / [email protected], the line of text your will have to copy paste is this one:
while :; do sleep 2; echo -n "TEMP: ";cat /sys/devices/virtual/thermal/thermal_zone0/temp;echo -n "FREQ: "; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq; done
Click to expand...
Click to collapse
5) This will auto-run every 2 seconds until you stop it, temperature is in Celsius and Frequency is in Hz (384000 Hz represents 384 Mhz), the sensor we are reading gives an average CPU temperature based on the actual load and expected load, this is natively done by the tablet. If you want to read a more accurate sensor you can change the thermal_zone0 for thermal_zone7, the difference should not be much but on stock kernels that sensor sometimes doesn't report any temperature and you will see an error. If you are using @franciscofranco kernel (http://forum.xda-developers.com/showthread.php?t=2446431) you can read sensor 7 always, and it's recommended.
If you find this little trick useful, enjoy it, just thought that someone could use it.
P.D.: You can run this as well on a Terminal from Android.
ADVANCED: If you know a bit about what I did in that command, you can tune it as you like to do whatever you want, here is a breakdown of what this command does.
while :; (this is what keeps the infinite loop going)
do (the trigger to start running commands)
sleep 2;(basic sleep command works as a timer, this is in seconds)
echo -n "TEMP"; (We write a text line to identify the 2 values, with -n operator we do it in the same line as the next order)
cat /sys/devices/virtual/thermal/thermal_zone0/temp; (we output the temperature value from the following file with a cat )
echo -n "FREQ"; (We write a text line to identify the 2 values, using -n again gives us another line of text)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq;(we output the current cpu speed value from the following file with a cat )
done (this is how we tell the while loop that we are done with commands and that it should run again)
You can give this script some other uses, like creating a log file with sensor readings to measure per example, battery drain, or signal strength.
Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"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"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill
* processes with a oom_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips
B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.
[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?
Just in case..
mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
@androcheck
Thanks for the encouragement..
nice tutorial with full descriptions...great..:good:
This is wonderfull! I will add this to the tutorial Index this weekend
mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you
thx u very much for the detailed explanation, gonna try ur recommended values later
great bro can be a sticky thread
mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS
This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think
Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...
Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).