Maybe it will be good to implement a long sleep mod to our phone to be able to stop phone ( even if it's not really ) and to keep fastboot kernel.
I mean an option that unload all system and keep only kernel in memory and that re-load all system when long press at start button ( I don't know if it is possible ).

There are numerous "hot" reboot apps in the market that reload the android GUI without touching the kernel.

killing system-server do the same....

but as i understand, the goal is something similar to "standby"

e.g. something like echo mem > /sys/power/state

i have not strong memories, that i tried that one, but was not able to wake the phone after ....


at least for now having a charger around is not so bad workaround

Originally Posted by peshovec

killing system-server do the same....

but as i understand, the goal is something similar to "standby"

e.g. something like echo mem > /sys/power/state

i have not strong memories, that i tried that one, but was not able to wake the phone after ....


at least for now having a charger around is not so bad workaround

Yes something like that. The goal is to have phone like halt but without losing fastboot kernel. In case of no charger or when phone have to be stop.

Have you read about KSM? sounds like a good solution for our RAM problems but I don't know it its possible to use it, since it appears to be 2.6.32+

i run some tests, (look at the screenshot -> uptime)




so far my current config seems stable

differences from the default:

kernel:
https://github.com/CyanogenModXT720/...0-test-patches

highlights of them:
swap enabled, 800Mhz by default (imho no need to overclock anymore)

in the attached fastboot.zip you will find the boot-custom.img :

highlights of using it:
the above kernel
no 2nd init (as with fastbooting imho it is needless)


p.s. btw, using auto process purging once a day, seems very good to avoiding memory pressure

Sweet!

One concern... avoiding 2nd-init means that there are now two boot mechanisms to debug. If you bake the rootfs into boot.img, then you have to keep track of boot.img+ROM compatibility.

On the other hand, is there really any downside to 2nd-init and keeping a unified boot process for normal and fastbooted kernels? If there are actually any real disadvantages to 2nd-init, I think there has to be a more elegant and generic way to bypass 2nd-init rather than baking the rootfs updates into boot.img... we should be able to pare down the boot.img init scripts so that the /system/etc/rootfs updates are merged without using 2nd-init to restart /init. I pondered this a bit a while ago but I decided it's less error-prone just stick to 2nd-init.