Optimize RAM for S100/A1 on 2.2 ROM's

[Guest Intenso74]

Hi all,

I've been using FroYo for quite a while now, and I've noticed (and I think many of the other S100/A1 users as well) that the system kills foreground tasks way too fast.

My browser was even killed a few times while I was using it due to low RAM.

Can someone optimize the system task killer for the S100/A1's 256MB of ram? Or is this (nearly) impossible?

Thanks!

Intenso74

[Guest fear_factory84]

I experienced the same problem on A1 with lcr-f 1.1.0... now the current lcr-f settings are pretty good for me:

bash-3.2# cat /sys/module/lowmemorykiller/parameters/minfree

1536,2048,4096,5120,8192,10240

on /system/build.prop I have

dalvik.vm.heapsize=32m

you can try to lower this setting to use less memory..

What settings do you have?

Default froyo-metal settings are too aggressive on A1 and the browser gets killed for example..

[Guest xdxdxdxdxdx]

swap it……

[Guest L0cu7us]

seems we don't have the setting:

dalvik.vm.heapsize=32m

on FroyoMetal /system/build.prop.

[Guest DasTisu]

If you have root acces; use autokiller to change it.

[Guest L0cu7us]

If you have root acces; use autokiller to change it.

not for dalvik ;-)

[Guest Dario93]

seems we don't have the setting:

dalvik.vm.heapsize=32m

on FroyoMetal /system/build.prop.

Our fault,as always. Thanks very much for your report, V3 will have the heapsize setting integrated :(

[Guest fear_factory84]

I've set my dalvik vm heapsize to 24m, on my lcr-f.. and I'm trying to use it. I have never used benchmark, but regular usage performance is the same as before (32m). Instead I have now 75m of free ram with all applications closed instead of 68M...

[Guest fear_factory84]

Our fault,as always. Thanks very much for your report, V3 will have the heapsize setting integrated :(

What is the default value of heapsize (if you don't set in build.prop)?

[Guest Dario93]

What is the default value of heapsize (if you don't set in build.prop)?

I'm not sure,maybe 24 MB?

[Guest Dinmamma]

It's 32m afaik.

[Guest L0cu7us]

Our fault,as always. Thanks very much for your report, V3 will have the heapsize setting integrated ;)

i've found this option into /default.prop and it is set to 27m :(

what it does exactly ?

How to choose the 'size' ?

Edited December 30, 2010 by L0cu7us

[Guest vache]

i've found this option into /default.prop and it is set to 27m :(

what it do exactly ?

How to choose the 'size' ?

Yep, it's in the default.prop in the radmsik, that's why it's not in the build.prop. And tha value is not intend to be change.

[Guest studjuice]

you need to use autokiller to optimize your free ram. the dalvikvm is different, though 32 should be set best for it if you are going to have JIT enabled. js

[Guest mik93250]

on froyo autokiller uses a lot of battery :/

[Guest studjuice]

yeah it does, that's the caveat, can't really use any type of management on froyo. the true solution lies in a well made kernel, good lucky finding one

[Guest jayziac]

I've been wondering the same, since most of the current ROMs (Official Froyo and Liquid Metal) were designed for the Liquid E 512MB, so the default settings were probably intended for that. Has anyone tried other settings on A1 256MB and noticed any improvements?

[Guest HIN_____]

swap might be the ultimate solution?

[Guest Small_Hacker]

swap might be the ultimate solution?

BUT SWAP IS NOT AVAILABE UNDER 2.2

[Guest Auxx]

Just use T&L ROM.

[Guest chiksum]

BUT SWAP IS NOT AVAILABE UNDER 2.2

then swap is the ultimate solution for Intenso74 and 2.2 rom's users :unsure:

[Guest Small_Hacker]

then swap is the ultimate solution for Intenso74 and 2.2 rom's users :unsure:

Hope LCRF2.0 may use this function

[Guest Harness]

I'm not sure,maybe 24 MB?

Set in default.prop 27mb. Leave it that way.

Harness.

[Guest fear_factory84]

swap is not a good solution, because background apps are taken in memory (or badly swapped to disk), and when the background app is reactivated it takes more than restarting it.

When froyo autokiller kills an app, it signals the app to save its state. If the app is properly written, when it's restarted state is restored. Not all apps honor this :unsure:(

So definitely swap to sd is not a good solution. ramzswap (compressed swap on ram) could be better than nothing, but it should be compiled in kernel and activated (lcr-e 1.8.x, eclair) supports it..

regards