Database Info

128MB and cache performance

for anyone who has upgraded to 128MB device, I've been doing a little research into putting all that extra RAM to good use and imroving the preformace of the Universal.
Had a little more time to sit down and test the pagepool think properly. Don't actually think that changing it made any difference and we're probably better off with having none (And it shouldn't really make much difference when I think about it)
Have tried both "Beast & Leos" and Ivans latest. There are a couple of things which make a big difference. First up is increasing the Glyph cache. The optimum value I found was around 65536.
The second thing that seemed to make the most difference was the File system Filter Cache. I set this at 16384.
I've set the File system cache to 8192. Though not sure of the benefit yet. There may be a link between the performance and the highresources cab but still investigating this.
With these settings at reset I get around 68Mb of RAM free. Not much free if your still on 64MB RAM!
The difference to system performance is marked though. One of the best examples is loading up the windows folder which usually has a noticable lag is "almost" instaneous. The TCPMP benchmark I got with the tweaked settings was 322% playback speed and 2.5Mbit/sec transfer rate. For this test setup this is by far the best performance obtained on any ROM I've tested.
PS Am also using the performance tool to OC to 624Mhz Dynamically.

WizP said:
There are a couple of things which make a big difference. First up is increasing the Glyph cache. The optimum value I found was around 65536.
Click to expand...
Click to collapse
How about the value 131072 (decimal) or 20000 (hex)?
How would that change your test keeping everything else the same?
WizP said:
PS Am also using the performance tool to OC to 624Mhz Dynamically.
Click to expand...
Click to collapse
How is the effect on the battery?
Best regards,
KOR!

King of Rapture™ said:
How about the value 131072 (decimal) or 20000 (hex)?
How would that change your test keeping everything else the same?
How is the effect on the battery?
Best regards,
KOR!
Click to expand...
Click to collapse
Seemed to make things slightly slower at 131072, but am curious to see how other fair!
As for the battery if anything the battery life is slightly better. - I'm not running processor intensive applications all the time to while the Universal is "snoozing" its should be sitting around 300Mhz.
Does anyone know exactly how this app works? I am curious as the other tools I've use i.e. Pocket Hack Master always show the processor speed in TCPMP but this little app doesn't. however adjusting the speed does appear to change the playback percentage!

hi WizP,
you are absolutely right! the processor does slow down to 300Mhz when no app is running.
i'm using Battery Status today plug-in by Chi-Tai DANG (freeware, found here at xda-dev) to display CPU speed & it does shows 300Mhz when CPU is idle.
the performance tool really works, although i don't overclock beyond 520Mhz. i use the performance tool more for battery saving than for it's overclocking facility.

Raphael is brutally closing programs!

Raphael is brutally closing programs!
I really dunno why is this happening... I have 50% of RAM free and it lets me run just 3-4 programs together. When I run one more... it occasionally selects one thats previously ran and kills it silently... I really wouldn't like to "Clear Storage" from settings

I also had this problem when I first got my TP. It's a simple fix - you need to disable AutoKill. With a registry editor, go to HKCU\Software\HTC\TaskManager, and change the value of “EnableAutoKill” to “0".

^ yes this a good fix. I remember I couldnt switch between opera and replying to a text message, I felt like I was back to a feature phone, with one thing at a time capability.
There is also a registry tweak that instead of killing apps you can change the threshold at which the system starts auto-killing, same registry path.

You guys are amazing! THANK YOU! BUT... I still have the problem
Any other ideas?

You can refer to this thread:
http://forum.xda-developers.com/showthread.php?t=426585
In the section of "Tips", there is a tweak which solved the problem perfectly

Thank you. Tried that caches tweak, it made whole system run much faster. But still - i cannot seem to get 4 proggies to run at the same time. Always the first dies... flip flop

This thread is turning into a copy of few others around here. Only this is new and alive.
Please help me out.
I've tried:
1) The HTC Task Manager registry tweaks
2) The cache sizes maximizing
and...
3)?
Maybe the ugly 32MB/32Process limit (http://msmobiles.com/F/viewtopic.php?p=36334&highlight=&sid=c6b5982e059ec35ce19fd3cd952bd683) is still present in WinMo6.1?

Hello!
OMFG! After disabling autokill my TP started to act almost like desktop in case of multitasking
I was able to run around 12 programs at a time, but i've also made changes to memorytreshold, the value i set was 173015040 (1.5 times the default value).
The funny thing was that TP was still responsive to commands and even opera ran smoothly when surfing throu light web pages.
First app closed after memory usage peeked around 65%, but the rest was still responsive.
Hope this helps
BHole

Thats my point. Same limit like 65% because I have customized my device with launchers, hardkey remapper, Wktask etc. Now I can have (only) five apps running at a time... Is there a sort of free RAM threshold inside the WM6 or HTC-s stock (1.9) ROM. Maybe it is still the 32 process limit from the old times?

Hello!
It looks like there is some kind of limit to number of proceses or memory used by them but if you customized your pda maybe you should disable some of the oryginal programs that are runing in the background. I saw some registry entries in taks manager that hid some of the runing aps maybe not all of them are nesesery for you and can be disabled to lower proces count.
BHole

Yeah.. but I would like to USE the RAM the device has.... I'd like to run manymany programs so the RAM load would be for example 95%. Why is not that possible?

Discussion on User.conf/tweaking AOSP ROMs

I shared my user.conf a while back with the guys on the xROM thread. I got really positive feedback from them so I decided to share it in a few other threads. JAC is included a lot of my ideas in xROM 1.4 and is going to include more in 1.5 It has grown and become more popular so I decided to start a thread at the request of a few people who use my config.
I didn't think it deserved the space until now to make a thread so I never started one. I'm not trying to make this thread all about me. I've said more than once, I would love for someone to come up with a config that is better than mine because I will be the first one to use it. I just don't want to keep derailing other conversations in other threads anymore. And while I appreciate all of the emails that I get, I think a separate thread will be an easier place to discuss this and help people out.
So I will start by posting giving a general outline of how I came up with my settings. If you want to give me feedback, I appreciate it. Even if you have emailed me in the past or posted something on one of the threads I would appreciate a post in this thread. If only the people who have problems post here I won't know how many people it is helping or not.
That is only part of the thread though. If you have a configuration that you have seriously tested and you want other people to try it, post your method and how to set it up and let's see what we can come up with. Please don't just post random configs hoping someone else will test them for you. I don't want the thread to turn into a confusing mess that doesn't help anyone. My goal is to have this thread spawn some new ideas that will make everyone's phone faster. If you've done your homework and you think you have something good, let's share it. I never thought that my config would be used by so many people. I was just trying to make my phone faster. Maybe you can do better.
Testing Method:
I generally use two apps to benchmark the performance of my phone. They are Benchmark Pi and Benchmark. Both are available on the market. I use Benchmark Pi for a rough comparison because it is faster and focuses mostly on how fast the CPU is running. When I get down to fine tuning I use Benchmark. It takes longer to run but it measure graphics, CPU, memory, and filesystem performance. For Benchmark Pi I usually will run it 10 times and use the average response. With Benchmark I set it to run each bench 5 times each and it automatically averages the values. Then I export that to a csv file and compare them that way.
I think I am a pretty heavy user of my phone so I took what I normally use and added a little bit to it. Here is what I used:
- All testing was done on xROM
- Over 120 apps installed
- 5 home screens
- 18 widgest and 8 shortcuts to apps (I can post specifics if anyone cares)
- I run the phone until it is definitely swapping. I play music, open large web pages, run CPU intesive apps, etc.
- ask me if you want more details
I use Advanced Task Manager, which I highly recommend, to keep an eye on what is running and kill any apps that are not being used by me or my desktop. I try to simulate heavy usage of my phone with only the things running that should be. I also use cat /proc/swaps, free, and sh /system/bin/swap -s (sh /system/sd/userinit.sh -s for othe ROMs).
I started out comparing Compcache and Linux Swap since those are the biggest choices. Compcache came out slightly better with the recommended configs that I could find at the time. Then I benchmarked and tested each of the Compcache settings. I found huge improvements made from tuning Compcache, especially adding backing swap. I know it got a bad rap in earlier builds because, well, it probably wasn't very good. But 0.6 is good and it has a bright future. Read this article http://lwn.net/Articles/334649/
Then I tuned swapiness, CPU, and tried on VM. It was mostly just painstaking, tedious testing of one setting to the next. I can honestly say that I have tuned every setting in the User.conf. If I change any of them the benchmarks go down. So when people tell me they tweaked this or that I don't want to say anything because I have probably tested that exact scenario and I got worse performance. But maybe it is working for them, I haven't seen any benchmark numbers. I tried on the VM but nothing seemed to help very much and I didn't want to cause problems so I stuck with the default settings there. Maybe someone can come up with better settings for the VM if that is their area of expertise.
Results:
I'm not going to post some grand report like I would at work. I'm not getting paid for this. Plus not very many people would look at it and I don't know how much it would mean in the long run.
The easiest comparision I can make is using Benchmark Pi. The average of all of the users who have ever tested using that app is around 15 seconds to calculate pi. Stock G1's will calcluate it in about 16 or 17 seconds depending on how loaded they are. xROM stock was getting a result of about 13.5 seconds with just scaling the CPU up to 528 MHz. After tweaking all of the other settings I got down to sub 12 seconds. My best time is about 11.6 seconds. I saw someone with 11.5 who used xROM 1.4. When I loaded CM 4.0.4 last night I was getting just under 13 seconds with my best times. Still a very good time considering everything that I have running.
I did a lot of other testing with Benchmark to monitor the filesystem and memory. I monitored /proc/swaps to see how much memory Compcache was using and how much was being swapped.
I learned a lot about the phone doing all of this. For instance, when you set the CPU max threshold really low, it is going to keep bumping up the CPU really fast until you get to the max. So you have a pretty good delay until you get to the max CPU frequency because the fequency keeps changing and pauses when that happnes. But then it is good until it drops again. If you make it too high, it will overwork the processor and you will see delays again. The key is to find the best setting that allows the processor to be exercised but not overworked. I don't have the time to write down everything I learned from it and you probably don't want to read it. But if you ask a specific question I will be happy to answer it.
I'd like to thank Huanyu for his thread (http://forum.xda-developers.com/showthread.php?t=542899). I wouldn't have been able to tune any of this without it and for JAC and Manup for helping me so much with xROM.
I hope this thread is helpful. Let me know what you think of my work and post your ideas too.
I have links to installing my User.conf in my signature. This post is long enough without putting that in here too. And this is more about discussion than pushing my settins on people. I don't know if mhy config will work at all with Hero. I haven't done much testing on it. I plan to do the same project for Hero when I have time. JAC has volunteered to help me out with that. If anyone wants to try it, go for it. But I don't want to confuse this thread too much by discussing Hero and the AOSP ROMs. Maybe I will start another thread for just Hero.
I look forward to seeing where this thread goes.

Ok, I decided to add more now that I have some extra time. I'm working to get backing swap working with a swap file instead of using a swap partition. A lot of people don't have or want a third partition on their phone and backing swap helps out a lot. Compcache 0.6 supports this but it wouldn't work on the G1 (or any ARM processor). I opened an issue with the compcache development team. They gave me a fix which allowed me to enable it but it ended up trashing my ext3 partition. I had to wipe my phone because the data became so corrupted. The issue is still open and the compcache developer is working on resolving it. When it is resovled, I will post an updated user.conf file that uses swap file instead of swap partition.

Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?

min scaling frequency 192000?
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!

fengwuyu said:
Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?
Click to expand...
Click to collapse
Compcache with backing swap uses the linux swap partition but it lets compcache manage both the compressed and non compressed storage. When a file can't or shouldn't be compressed it doesn't have to pass it back to the OS to deal with. It just moves it directly to swap. That is why it shows 100% good compression with backing swap turned on. All of my testing has shown that compcache + linux swap is much slower and more cpu intensive thand compcache + backing swap.

my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me

ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.

alapapa said:
my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me
Click to expand...
Click to collapse
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.

Yes, he speaks the truth. After updating to a recent Cyanogen ROM, my phone just got super clunky and annoying to use, so I set out to do a completely fresh install: resizing, reformatting, wiping, fresh ROM flash, and fresh app dls. I thought since I was stuck using the stock 1GB SD card (for now at least) that is inherently Class 2, it was causing me a major bottleneck since CC and BackingSwap both employ fair usage of your SD card. Well after updating to Cyanogen's 4.1.2.1 and installing all my apps, Benchmark Pi clocked in at about 15.5ms - 16.5ms using Cyano's stock CC settings built into his ROM. Next I pushed Taylor00's user.conf with the 0.1.4.1 userinit.sh. After rebooting, my phone clocked in at 12.6ms - 13.2ms on Benchmark Pi, a definite improvement.
-Maleko48

miketaylor00 said:
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.
Click to expand...
Click to collapse
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.

alapapa said:
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.
Click to expand...
Click to collapse
I believe that crontab is a part of busybox. You can use that.

I'm still not following
miketaylor00 said:
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.
Click to expand...
Click to collapse
What I'm confused about is the significance of choosing 192000 as a scaling frequency at all. My understanding is that the CPU can only run at certain frequencies and 192000 is not one of them. If you set 192000 as your minimum scaling frequency, doesn't that have exactly the same effect as setting it for 245760? Since there are no frequencies available between 122880 and 245760, any setting (for minimum scaling frequency) between those would default to the higher frequency, in this case 245760. Am I missing something here?
The reason I thought it might be a typo is because there is a 19200 frrequency available, but from all reports anything near that low will just lock up the phone.

ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
Here is a copy/paste of that section of the latest user.conf set with MT00's settings:
Code:
#cpu clock
proc_cpu{
proc_cpu_en=1 # enable(1) or disable(0) user cpu configurations
# freqency options
# 19200
# 122880
# 128000
# 245760
# 384000
# 528000
scaling_min_freq=192000 # default 245760
scaling_max_freq=528000 # default 528000
sampling_rate=2000000 # default 2000000 depending on kernel version
powersave_bias=0 # default 0, (200 since CM3.9.6+ )
up_threshold=45 # default 40, percent cpu usage before going up a speed step
While 192000 is not an option listed, here is the output of my userinit.sh:
Code:
C:\Documents and Settings\user>adb remount
remount succeeded
C:\Documents and Settings\user>adb shell
sh-3.2# sh /system/sd/userinit.sh -s
sh /system/sd/userinit.sh -s
=== user.conf ===
*** general ***
apps2sd=0
media2sd=0
*** CompCache ***
compcache_en=1
cc_memlimit=18
cc_disksize=32
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
swappiness=28
*** Swap File ***
swap_file_en=0
linux_swap_file_size=32
linux_swap_file=/system/sd/swap.file
*** Linux Swap ***
linux_swap_en=0
linux_swap_partition=/dev/block/mmcblk0p3
*** VM ***
sys_vm_en=1
page_cluster=3
laptop_mode=0
dirty_expire_centisecs=3000
dirty_writeback_centisecs=500
dirty_background_ratio=5
dirty_ratio=10
*** CPU ***
proc_cpu_en=1
scaling_min_freq=192000
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=0
up_threshold=45
=== CompCache status ===
CompCache version 0.6+
Compcache enabled
CompCache: MemLimit 18432(system) 18432(user)
CompCache: BackingSwap /dev/block/mmcblk0p3(system) /dev/block/mmcblk0p3(user)
CompCache: cc_swappiness - 28(system) 28(user)
=== CompCache status output ===
BackingSwap: /dev/block/mmcblk0p3
DiskSize: 32130 kB
MemLimit: 18432 kB
NumReads: 8048
NumWrites: 10222
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 3870
PagesDiscard: 0
ZeroPages: 177
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 4340
PagesUsed: 1060
OrigDataSize: 17360 kB
ComprDataSize: 4078 kB
MemUsedTotal: 4240 kB
BDevNumReads: 1233
BDevNumWrites: 1731
=== VM status ===
Set VM: page-cluster - 3(system) 3(user)
Set VM: laptop_mode - 0(system) 0(user)
Set VM: dirty_expire_centisecs - 3000(system) 3000(user)
Set VM: dirty_writeback_centisecs - 500(system) 500(user)
Set VM: dirty_background_ratio - 5(system) 5(user)
Set VM: dirty_ratio - 10(system) 10(user)
=== CPU status ===
Set CPU: scaling_min_freq - 192000(system) 192000(user)
Set CPU: scaling_max_freq - 528000(system) 528000(user)
Set CPU: sampling_rate - 2000000(system) 2000000(user)
Set CPU: powersave_bias - 0(system) 0(user)
Set CPU: up_threshold - 45(system) 45(user)
That setting seems to take.

You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.

miketaylor00 said:
You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.
Click to expand...
Click to collapse
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol

After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?

bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot

overground said:
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot
Click to expand...
Click to collapse
I'm on CyanogenMod v4.0.4. I clicked the link from this post which lead me to the code he had posted in another thread. I followed the instructions there. I don't believe the code was exactly what you have here. Will try. Thanks.

andonnguyen said:
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol
Click to expand...
Click to collapse
That is not true at all I just set mine to 192123. Are you telling me that is in the clock.c file?
Code:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
192123

bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Most likely you don't have a userninit.sh. If you are on CM 4.x it doesn't come by default. Follow the steps in this thread:
http://forum.xda-developers.com/showthread.php?t=542899

ram development "lets show google how its done"

ok its simple we all know the benefits of more ram. we all know that android slices up the ram into static addresses within the kernel. i would like to change that as we are in 2009 almost 2010 and we still rely on static ram allocation for the camera, gpu, sensors, radio. the g1 has 192mb of ram. yet we only get 97 for programs to use. i would like to place the camera, gpu, etc into dynamic addresses that we can change within the os without flashing a new kernel. a service, kernel code, module, or any other method could do this. we just have to make it happen. we could do it three ways i see.
1. a system managed ram allocation using a service to detect the percentage used and increase ram on the go.
2. a kernel script or service that only activates and allocates ram when needed. such as once a 3d program is loaded the 8mb magically comes back.
3. a virtual device ram allocation service that makes the device think it has the ram all along, but only actually gets it when it needs it. kinda like the way apps2sd works.
4.(by IConrad01) run perl scripts through ase and use ksplice to patch the gpu1 memory in kernel. one script on and one for off.
any other methods to implement this proper are very welcome and encouraged.
the idea behind this is a proper way to get back more ram for our programs. the idea is simple when 3d is not in use we can used the 8mb it would have used for something else. this applys to everything that has its own ram. camera, etc. say we did this and only got 120 free. thats almost 25% more ram. plus we could go the extra step and let the user choose how much each thing gets(gpu settings 4mb,8mb,12mb. camera on, off. etc) so when it needs it thats what it gets. great if you like/dislike 3d games.
on another note this is the kind of work that gets you noticed. the kind that gets you hired or gets you respect. google would be proud and might implement it and you and i know it. i hope we are successful and google uses it mainstream.
so lets debate a way/ways to do this
provide alpha tests of different ways to do this
and finally lets post a beta so everyone can enjoy.
atm ksplice with perl scripts is where we are going will update as this progresses.

Doesnt Jacs update to his hero rom have this, im probably mistaken

jad011 said:
Doesnt Jacs update to his hero rom have this, im probably mistaken
Click to expand...
Click to collapse
No. The current implementation of this basically cuts the graphics memory in half.
This would dynamically allocate the memory as needed. Much more efficient way of doing it.

he has a static change that takes the ram away from the gpu by a kernel edit. this is to have both more ram but still give the gpu what it needs to perform properly but only when it needs it or you chose to give it.

Are you referring to RAM or storage space? You say RAM in the title but then it sounds like you're talking about storage space before making me think it's RAM again later on. I'm confused :/ I'd really like additional free RAM, anything that helps reduce swapping to SD card is good but storage space I have plenty of.

all of this would apply to ram only. swap and compcache could use the same idea to dynamically allocate swap but that is still a cache for programs. sorry if its confusing. simple way to explain. i want all the ram i can get but still use everything the phone has properly, like games and the camera.

Gotcha and understood. I see so many people say RAM and memory when they're referring to storage space sometimes that I want to scream but extra RAM on the G1 would be more than welcome. Hopefully others with the brains to make it happen can do it

actually anyone with a basic knowledge can help. mostly there are a couple things to developing a good idea.
first the concept.
then ideas on how to do it.
next a map or guide to what does what.
coding different parts
putting them together
debug and test
even if all you do is photoshop the ui or provide ideas it helps. once some different people get aboard this should be working sooner than you think.

Of the three options listed, the kernel script (via ksplice) seems like it would be the shortest route to functionality, but frankly it also seems a bit... well, hackish -- when compared to the virtual device allocation scheme. It would take a hefty re-write of the kernel, I suspect, to accomplish; but being able to resize various devices on the fly would be a good thing. Shrinking CompCache based on real RAM usage for example would probably speed up the phone under light loads.
Just thinking in text here.

personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.

jokersax11 said:
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
Click to expand...
Click to collapse
The only problem with this is when the ram is divided, everything in it is cleared, thats why it is set at boot in the kernel. Think of it like repartitioning your SD. Now it would probably be possible have everything mapped to ONE big RAM table & then build something similar to a scheduler like BFS for RAM that would allocate it as necessary. This is messy though.
Just my $.02

well yes but it is possible to create shared memory through c++ http://www.go4expert.com/forums/showthread.php?t=8461
however i think the vm heaps has either a 6 or 16mb limit. anyways the service would basically do a memory patch over the kernel in realtime(like overclock) telling the gpu the memory is there all the time. meanwhile it allocates dynamic shared memory from the application memory for the gpu to read and write. meanwhile an app tied to a script would set the parameters and settings.

Okay -- I know ksplice works with perl; and I know that we can run perl scripts using the ASE .apk.
So... it seems to me that it /should/ be possible to use a patch that reverts the patched kernel back to the previous state, and a patch that switches the original state to the GPU1=0 MB state. From there, we could set up two scripts; one for GPU1-off and one for GPU0-on. Each would simply be an invocation of ksplice to input the specific patch (which would have to be stored on the sd card. [it would be safer if in the ext partition]).
We'd have to set up a secondary RAM device, rather than just adding it to the standard RAM pool... something like establishing it as a /dev/block/shm.
The point of all the above is that when you click on the GPU1-off script, it "reclaims" that RAM and gives you a device that's standard RAM. When you click on the GPU1-on script, it disables that device (forcing the reload of all programs using that RAM) and re-enables the GPU1 device.
Even better yet, the Android Scripting Environment program, much like GScript, supports desktop icons.
So -- very initially speaking, assuming we can get ksplice working on Android (which just requires a static binary, IIRC), we can get a simple pair of icons; one of which frees up the GPU1's RAM; and the other of which re-enables the GPU1.
Since the only times it's going to be "called up" are when a game is actively being played, or something similar, this should be a mostly-satisfactory route to begin with, before we can get into the whole scheduled/scaled script running as a daemon in the background.
Once we get /there/, then we can start looking at true virtual device allocations and shared memory and the like.
Although, I do have to say that I'm not entirely sure how comfortable I am constantly repatching the kernel. Definitely, we're going to want to recommend that people back up their original, unpatched, boot.img files!

IConrad01 i added your method to first post as it was a great start to this project. if you want me to rephrase just post what you want and ill change it. the only issue i might see is what geniusdog254 said it might unallocate the wrong thing and create a reboot. but some clever coding should prevent this.

Nah, that's all good.
There's an easy way to prevent it from becoming a reboot-able issue. Enable the GPU-space device as "swap". This could be done one of two ways; tell the phone that the new 8 MB RAM "device" is to be considered the /first/ swap device to be used, and just leave it "as is". The r/w times would be for true RAM. The other option assumes we have the latest CompCache (0.6+) -- as it allows for multiple instances of CompCache. The theme here should be obvious.
Either way, the result is that only swappable pagefiles would be lost when the device is turned back into GPU memory. No system-vital memory would get tossed. Seems simple enough to accomplish, perhaps. But then again, I Am Not A Programmer.

ok so what are the alternatives to ksplice for the swap device change. since we could make it swap/compcache anyways is it possible to change on the fly like the way overclocking widget does?

Ksplice allows you to make kernel updates and have them implement themselves without having to reboot the device. The swap device stuff would have to be implemented on a script-level. Two different things: I.e.; the script invokes ksplice to install a specific patch, which causes the kernel to recognize the newly freed-up RAM as a specific device (I.e.; such as /dev/ram1 as opposed to /dev/ram0). I am not sure I'm saying/thinking of this properly here: I'm operating on the edge of what I know about Linux.
Anyhow -- the trick is, when we get the kernel to disable the GPU's memory, we enable a new RAM-disc swap partition with its swappiness set to the maximum rating so it picks up everything first. Since it is /actually RAM/, it'll perform like real RAM. We're only 'declaring' it as swap in order to prevent forced reboots when turning it off.
The above wouldn't just be a ksplice thing; ksplice is just to implement daproy's kernel patch and thus free up the devoted memory to the GPU1. This memory would then be allocated to a new device (thus preventing the RAM-dump forced reboot) and /that/ would be set to swap status to ensure no "mission-critical" files go on it.
Then, once we get that built up, we just build it in "reverse" -- turn off swap (dumping its info back to the system, where CompCache / linux-swap would pick up the load) and re-enabling the GPU1.
Once we get /those/ built, we can then create a daemon script, include an invocation of it into the latest userinit.sh, and have that script basically monitor GPU0's load levels. If they go above a certain threshold (scaling, just like with the CPU), it would invoke the second script above, patching the kernel and re-enabling GPU1. This would then monitor the GPU, and once //its// memory load falls back down to where GPU0 can handle it all, turns GPU1 off and frees that RAM back up for individual use.
I can already foresee a complication where turning GPU1 off "on the fly" would cause a reload of all graphics, but... considering how rare it is to even pull a load above what GPU0 can handle in ordinary use, this isn't much of an issue. It'd take some tweaking and beta-testing (which I'm pretty much set to be a tester of at this point, apparently ) but that would be about it.
Now, //ideally// we could create an alternative solution which wouldn't rely on constantly patching the kernel. As I said; that can get... well, "messy".
I just don't know enough to know what that alternative path would be. Virtual shared memory space seems like it would be a good idea. An alternative solution could be something along the lines of enabling GPU1 at all times and simply having it call to a swapfile which is located in /tmp (I.e.; a non-compressing swap-file which is actually located in RAM). Said swapfile could be resized freely according to need and would thus be no issue at all.
Frankly, I can already see one reason why that would be a superior solution to all the ksplice shenanigans above: said swapfile could be made to be /larger/ than 8 MB, and thus actually provide for an increased performance due to higher available memory for the graphics side of things. We'd want some way to make sure that the swapfile itself wouldn't get pages dumped onto an actual swap partition. This seems like a much more elegant solution than the ksplice routine. I simply have no idea if it's even feasible. The swapfile would have to be mounted into /tmp (or it's Android equivalent) //at the time the GPU1 was enabled//. Is that even /possible/ at boot? Could we simply enable the device very late in the boot stage?
Quickly! Someone with /actual programming expertise/, rescue me from my aimless mental tinkering!

Since it seems there's little activity in this thread, I thought I'd share:
There is a debian armel package for ksplice.
( http://packages.debian.org/squeeze/ksplice )
This is ARM-compiled. We would simply need to cobble together a script which invokes ksplice properly. I myself know nothing of how this would be done.
Usage example of ksplice here:
http://www.ksplice.com/example-update

Looks pretty simple. You just need a working kernel build environment. Anyone got one of those laying around? I have wanted to do that for awhile but am too lazy to set up a linux VM, lol.

Hell yeah!!
Im not much good for this project other then willingness to try betas and give feedback, but I'm excited to see where this goes.. It would be great to reclaim the ram being used from the system when you aren't using anything that needs it and use it for what you are using. Has anyone contacted one of the devs that have been modifying the kernels and ask them if they could try building it with the ksplice functionality?? I would think one of them would be happy to build it so you can start playing with it. Wish I could help more on it, but this is a little above my head, but I will be following this thread and learning what I can as i go.. Good Luck!!

is there anyway to increase programs launching speed?

is there anyway to increase programs launching speed?
i ask this because every time i open up a program on my windows phone, it takes about 2 to 3 secs to load up something (there is just a rotating wait cursor), and the program appears then.
both my omnia ii and hd2 are suffering this problem.
i am wondering if the launching program speed could be increased by doing something? say changing some registry or increasing papepool size?
thanks!

You could use a task manager to see if your memory is not taken by some other process, you can also use overclocking, but don't forget that some programs need to cache or load database before starting.

Quite a lot of things can slow the launch down. Does it the program live in main memory or on a storage card? If it is the latter it has to be read out of the card into main memory before it can be launched.
If the application was written in .NET CF, VB C# etc., and especially if the application is quite large, there is a hit in performance while the JIT compiler converts the IL instructions in the executable to native ARM code in order to able to run it.
If the .NET executable is on a storage card then the delays above get combined.

I think cook rom with 12M pagepool would be good enough. I current running 6.5 with with config running like cham~

hungelt8 said:
is there anyway to increase programs launching speed?
i ask this because every time i open up a program on my windows phone, it takes about 2 to 3 secs to load up something (there is just a rotating wait cursor), and the program appears then.
both my omnia ii and hd2 are suffering this problem.
i am wondering if the launching program speed could be increased by doing something? say changing some registry or increasing papepool size?
thanks!
Click to expand...
Click to collapse
Open the program then go to the today screen. Open task manager and add the running program to the exclusive list. Now each time it is opened you should notice less lag. More ram will be in use however.