yashsingh1/xdaforums huggingface dataset:
[G 2014 Android Development] solzhenitsyn:
DiamondPizza, have you any ideas?
[G 2014 Android Development] roulyz:
Installation:

* execute with root (check off the cross bones & skull)

Where check off cross bones & skull ?

* choose a profile (temp or perm) & then select boost

Explain please
[G 2014 Android Development] Vedant Mistry:
The root(superuser 'XD') icon should be enabled(green)
[G 2014 Android Development] solzhenitsyn:
I discovered the problem, you have to enable "mount system as rw" in Smanager options

Might be worth adding to the OP.
[G 2014 Android Development] DiamondBond:
Strange since the script does this automatically, however thanks alot ill add it to the op in due time :)

Sent from my Moto G 2014
[G 2014 Android Development] GRLDT:
Hey, I just realized that I typed the command wrong. It's actually working on my phone! :D

Sent from my SM-G7102
[G 2014 Android Development] seliver:
I needed to do this on stock kitkat rom.
[G 2014 Android Development] albertopaz:
Can i use in Sprit kernel r13 and in 5.1.1?
[G 2014 Android Development] seliver:
BB option doesn't work. Workaround: try changing the option to C or something like that (lines 58 and 76)
[G 2014 Android Development] GRLDT:
I think it's case sensitive.
[G 2014 Android Development] DiamondBond:
this is deprecated , refer to hybridmod @ my github, its got alot more features, way better code and it runs better, anyways when its released or ready to be used daily ill pop out a notification on the hybridmod thread :)

edit

https://github.com/HybridMod
[G 2014 Android Development] reeeju:
Can i use it with euphoria os....
[G 2014 Android Development] DiamondBond:
no, dont use this script lol, im removing the download links, i honestly discourage any use of this script, it has very linear code structure and just works, nothing in here is dynamic for any other devices and etc... wait a few days/weeks/months for hybridmod to release, when it does, you will enjoy it :)
[G 2014 Android Development] reeeju:
I m sticking with euphoria rom....so i m waiting for ur post
[G 2014 Android Development] seliver:
So then how does one removes this from the device which has this script applied?
[G 2014 Android Development] solzhenitsyn:
Does this work like a minfree manager?
[G 2014 Android Development] devsk:
You can run logcat like this:

$ adb logcat -v time -d | grep Killing | head -1

$ adb logcat -v time -d | grep Killing | wc -l

$ adb logcat -v time -d | grep Killing | tail -1

This will show how many kills happened and in what range of time.

Collect the above data at following times:

1. Immediately after the boot up. This is to measure how the apps are getting killed and restarted at the boot up time.

2. Every 1 hour after an uptime of 6 hours. This will show you that killings and restarts continue to happen whether you are doing something with the phone or not.

And once you look at the data, get ready to get startled to know how buggy the lomemorykiller kernel module is and no matter what combinations of minfree you try, its a mess...:)

And, if you get time, go ahead and star this issue: https://code.google.com/p/android/issues/detail?id=98332

The fix is not in tuning the settings. Trust me when I say that because I know a thing or two about Linux kernel. I spent over a week trying various combinations of settings and always ended up in mess with lowmemorykiller still getting engaged and ruthlessly killing apps.
[G 2014 Android Development] DiamondBond:
Yep :)

Sent from my XT1068
[G 2014 Android Development] DiamondBond:
yes basically it does ;)

Sent from my XT1068
[G 2014 Android Development] DiamondBond:
Thanks for your insight :) I will logcat this and see how it goes and I'll star the issue soon, i still say that things are smother and have less redraws with my minfrees enabled... ;D

Sent from my XT1068
[G 2014 Android Development] truestory88:
This script solve the problem with ram? I can use this script in any ROM?
[G 2014 Android Development] DiamondBond:
Yes :)

Sent from my XT1068
[G 2014 Android Development] unwired:
For me logcat | grep Killing only shows someting like

01-21 10:25:40.652 I/ActivityManager( 947): Killing 11220:com.motorola.MotGallery2/u0a17 (adj 15): empty #7

which I think is almost normal and uncritical behaviour because it only shows killing of "empty" (unused) processes.

You should rather run

$ adb logcat -v time -d | egrep '(has died)|(restart of crashed)'

and if you see something like

01-21 10:28:34.720 I/ActivityManager( 947): Process com.whatsapp (pid 13146) has died

01-21 10:28:34.767 W/ActivityManager( 947): Scheduling restart of crashed service com.whatsapp/.messaging.MessageService in 4000ms

01-21 10:28:34.964 I/ActivityManager( 947): Process com.fsck.k9 (pid 6812) has died

01-21 10:28:34.965 W/ActivityManager( 947): Scheduling restart of crashed service com.fsck.k9/.service.PushService in 13802ms

you need to tweak the lowmemorykiller settings because these lines show running background services that were killed.
[G 2014 Android Development] meadillas11:
A cleaner way to set those setting would be to add these lines at the end of /system/etc/init.qcom.post_boot.sh

Edit:

echo "3" > /proc/sys/vm/drop_caches;

echo "3" > /proc/sys/vm/drop_caches

Balanced

case "$target" in
"msm8226")
echo "6236,8463,10913,16481,18931,22272" > /sys/module/lowmemorykiller/parameters/minfree
echo "80" > /proc/sys/vm/swappiness
echo "10" > /proc/sys/vm/vfs_cache_pressure
echo "3000" > /proc/sys/vm/dirty_expire_centisecs
echo "500" > /proc/sys/vm/dirty_writeback_centisecs
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_backgroud_ratio
echo "1" > /proc/sys/vm/overcommit_memory
echo "150" > /proc/sys/vm/overcommit_ratio
echo "4096" > /proc/sys/vm/min_free_kbytes
echo "1" > /proc/sys/vm/oom_kill_allocating_task
echo "3" > /proc/sys/vm/drop_caches
;;
esac

Multitasking

case "$target" in
"msm8226")
echo "4444,6031,7777,11745,13491,15872" > /sys/module/lowmemorykiller/parameters/minfree
echo "80" > /proc/sys/vm/swappiness
echo "10" > /proc/sys/vm/vfs_cache_pressure
echo "3000" > /proc/sys/vm/dirty_expire_centisecs
echo "500" > /proc/sys/vm/dirty_writeback_centisecs
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_backgroud_ratio
echo "1" > /proc/sys/vm/overcommit_memory
echo "150" > /proc/sys/vm/overcommit_ratio
echo "4096" > /proc/sys/vm/min_free_kbytes
echo "1" > /proc/sys/vm/oom_kill_allocating_task
echo "3" > /proc/sys/vm/drop_caches
;;
esac

Gaming

case "$target" in
"msm8226")
echo "10393,14105,18188,27468,31552,37120" > /sys/module/lowmemorykiller/parameters/minfree
echo "80" > /proc/sys/vm/swappiness
echo "10" > /proc/sys/vm/vfs_cache_pressure
echo "3000" > /proc/sys/vm/dirty_expire_centisecs
echo "500" > /proc/sys/vm/dirty_writeback_centisecs
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_backgroud_ratio
echo "1" > /proc/sys/vm/overcommit_memory
echo "150" > /proc/sys/vm/overcommit_ratio
echo "4096" > /proc/sys/vm/min_free_kbytes
echo "1" > /proc/sys/vm/oom_kill_allocating_task
echo "3" > /proc/sys/vm/drop_caches
;;
esac
[G 2014 Android Development] DiamondBond:
Thanks for the logcat :) question what minfree values were you using? Balanced right? I might have to adjust them some :) however try with the multitasking ones, they keep stuff alive

Yes but these settings are applied temporarily, I will make a permanent option to install them to that location or init.d, however thank you for telling me about this location for where the values can stay instead of init.d which stock Roms don't have without an extra app ;)

Sent from my XT1068
[G 2014 Android Development] meadillas11:
You are welcome, all credit for this "trick" to freeusername who figured it out. ;)

http://xdaforums.com/showpost.php?p=57491847&postcount=29
[G 2014 Android Development] DiamondBond:
****! thats golden stuff but the lmk values are too weak imo, however he states he uses UKSM & sets swapiness to 100 (pretty unstable imo, i would set mine to 80...) and he is using zram...

testing time xD i will see what i can do via using zram & ultra kernel samepage memory! and will share any info about it.

those LMK values are pretty low, with them you might expirience some frame stutters in ui navigation, however it does keep things alive, i might try make it just a tiny bit more agressive, not too much, ill bake these values into the script and post an update now :)

however i want to keep it temporary for the time being, no permanent stuck values, since the values i am using and everyone else is from this script are too strong, so untill i find the perfect lmk values i wont make these values "permanent" (can be removed from init.d, but i prefer to keep things simple for users atm...

Hope you understand ;)
[G 2014 Android Development] TheKerevas:
For if this script also works with the script installed on the device Nitro X Spark Edition ?
[G 2014 Android Development] DiamondBond:
yes :)

Sent from my XT1068
[G 2014 Android Development] devsk:
Did you collect the stats after fresh boot? Can you post them?

Anyway, you are looking for crashed processes getting restarted by activity manager. App crashes have nothing to do with lowmemorykiller module. Note that I refer to "crash", not clean exit. See below.

Now, its possible that those processes actually died gracefully in response to lowmemorykiller generating the onLowMemory() callback in the application and application deciding to exit in the face of low memory condition, and then activity manager just restarted them. But it takes you back to the same bug as all those other "background empty" processes getting butchered! The question to be asked is why is lowmemorykiller killing all these processes (and there are 300 kills on my phone within the first 2-3 minutes of phone booting)? There is plenty of free RAM (at boot up I have 310MB of real RAM free, real being the keyword) to fit in at least 10 processes but it still decides to kill (or send onLowMemory() callback to the) apps. There is absolutely no reason for killing and restarting apps (background empty or not) repeatedly, hundreds of times in a day when you have plenty of memory available and the system is idle i.e. user is not even touching the phone, let alone firing new apps.

You should really read the bug I filed. There is plenty of useful information and analysis there.

Tuning the minfree parameter (*) down does not alter the behavior long term. It just postpones the problem for some time (may be couple of hours at most). And that's where my point of collecting kill stats every 1 hour for extended period of time comes into picture. Run a script in the background and see for yourself.

PS: BTW, it kills the firewall process because its tagged "empty"!! And it does that on Samsung S4 which has 2GB of RAM.

(*) I have a strong feeling that minfree parameter is not even working correctly e.g. try extremely low number for the last value i.e. the empty processes. It should not kill even the empty processes if it has more than that much of RAM free. But it does kill them although more than enough RAM is free. This is what I want to investigate in the bug I filed.
[G 2014 Android Development] truestory88:
I used this script. Thanks for your job! I try this script in Titan Rom and it's better. Could you please change minimum free memory? I have never seen free memory below 160mb with "super multitasking"
[G 2014 Android Development] TheKerevas:
Installed, if it still works after restarting the device?
[G 2014 Android Development] hoopas:
"On reboot values are lost" its in the op;)
[G 2014 Android Development] StariX37:
Compatible with CM 12.0 ??
[G 2014 Android Development] DiamondBond:
Welcome! :) free memory is wasted memory, you don't need so much free memory... ;) and my free memory is always around 200mb... I use greenify and the super multitasking minfrees but with swapiness at 60 and cache pressure at 100. (testing new values)

Yes :) use the unamed kernel as well, it will help even more since Luca updated the lmk driver!

Sent from my XT1068
[G 2014 Android Development] DiamondBond:
Thanks alot for all this in sighting info! :D

I looked at the filed bug info on the Google source code page (that's yours? Right?) And yes it seems that the lmk is weird on the s4 as well, but not m8... Its strange... I will do some research on that extra lmk value the m8 has ;)

But thanks so much dude for all this info, it helps a lot for us to know more about the lmk and why its so agressive even when changing minfree values!

Sent from my XT1068
[G 2014 Android Development] freeusername:
zram + uksm shouldn't make a big difference on this issue, but if you want to implement them must say i used google snappy instead of lzo for compression/decompression and uksm with hash strenght set to 1.

Another thing this must sound a bit weird, but i did not experience the issues people was talking about in my phone maybe because i started developing my own kernel since the day i got the phone, and noticed the lmk values were too high so i changed them and after reading the thread thought it might help ... no need to credit me for those values thought, they are simply the aggresive settings from the minfree tool, but thanks. About init.d, should work fine if you make sure init.d runs after the post boot script, but since i wanted to move dalvik cache to /cache to save space on /data i had to make them run earlier on but the values wouldn't stick after reboot because the moto default ones are set up later on, and adding them at the end of post boot sh fixed that problem. Of course there're a lot and better ways to get around this problem. But whatever works ...
[G 2014 Android Development] devsk:
So, just prove my point that LMK was not really honoring the minfree values we were feeding it, I added the following in /data/misc/mytweaks.sh and added a line to /system/etc/:

root@titan_umts:/ # tail -1 /system/etc/init.qcom.post_boot.sh
/data/misc/mytweaks.sh &
root@titan_umts:/ # cat /data/misc/mytweaks.sh
#!/system/bin/sh
# increase the zram to 350MB
swapoff /dev/block/zram0
echo 1 > /sys/block/zram0/reset
echo 357772160 > /sys/block/zram0/disksize
mkswap /dev/block/zram0
swapon /dev/block/zram0
# don't have a lot of dirty memory
echo 5000000 > /proc/sys/vm/dirty_background_bytes
echo 5000000 > /proc/sys/vm/dirty_bytes
echo 100 > /proc/sys/vm/overcommit_ratio
# save battery
echo 384000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
function keepFirewallAlive()
{
while true
do
if [[ -f /proc/$(pidof com.jtschohl.androidfirewall)/oom_score_adj ]]
then
echo -1000 > /proc/$(pidof com.jtschohl.androidfirewall)/oom_score_adj
touch /dev/.adjusted
fi
echo -1000 > /proc/$$//oom_score_adj

# keep freeing the page/buffer cache to see if LMK still gets engaged and kills
echo 3 > /proc/sys/vm/drop_caches
sleep 5
done
}
keepFirewallAlive &
# keep very low thresholds for LMK
echo 1024,2048,4096,4096,6192,8192 > /sys/module/lowmemorykiller/parameters/minfree
# don't try to keep too much memory free
echo 1024 > /proc/sys/vm/extra_free_kbytes

Basically, the goal was to keep my firewall app UP as long as possible. So, every 5 seconds I am dropping the caches, and adjusting the oom score of firewall process to -1000 to make lowmemorykiller ignore it.

I run the following in a terminal window to watch how LMK is behaving with respect to free memory available:

$ while true; do adb shell "free;uptime;date"; adb logcat -v time -d | grep Killing |head -1 ; adb logcat -v time -d | grep Killing |wc -l ; adb logcat -v time -d | grep Killing |tail -1;sleep 5;done

So, I look at the kill data in conjuction with free memory. Its basically, drive by shooting...:D There is plenty of memory free and LMK is still killing. Look at the parameters I am feeding it. They are low (like 32MB for empty class). But it kills even when we have 100MB real free RAM.

So, its a bug in the LMK code or the VM shrink callbacks in LMK are being called by the Linux VM even when the system is not under memory pressure.
[G 2014 Android Development] TheKerevas:
I put the profile SuperMultitasking and opened some apps including FB and the return recharged again. How so ?
[G 2014 Android Development] DiamondBond:
Hmm then it looks like tuning lmk doesn't do much than postpone the effects... Well its better than it closing instantly but thanks a lot bro for that super scientific study :D its super accurate and good readings!

so lmk does not care about the minfrees! Moto or The big G really f*cked up with the code somewhere to casually wreck the lmk... I mean its "only" one of the most crucial parts to multitasking, xD I want to try cm12 by Luca and his unamed kernel since it has new lmk drivers, which might fix this issue! :)

Again thanks a lot for your time and results!

Sent from my XT1068
[G 2014 Android Development] DiamondBond:
Sorry I don't understand what you implied?

Yes that's correct, well if it ran without errors, that's good, must have automatically granted permissions / had permissions from before, :) hope you like it! BTW uncheck the boot option since it won't automatically apply values on boot ;) it will just confuse smanager...

Sent from my XT1068
[G 2014 Android Development] TheKerevas:
Background applications do not continue from where I was
[G 2014 Android Development] rffslow:
I tried the 1.1 here with supermultitasking and yes, if i open facebook and then spotify, when i go back to facebook in like 10 seconds, it doesn't reload.

Didn't tried to let more time on background.
[G 2014 Android Development] TheKerevas:
But the problem is the app? It can solve ?
[G 2014 Android Development] DiamondBond:
Um if you mean can the app stay running in bg then yes it can via super multitasking minfrees ;)

Sent from my XT1068
[G 2014 Android Development] TheKerevas:
E 'already SuperMultitasking and same close...
[G 2014 Android Development] devsk:
Latest update at https://code.google.com/p/android/issues/detail?id=98332#c6 after 2+ days of uptime with my tuning script.
[G 2014 Android Development] luca020400:
Hmm

Increase the zram size isn't a good choice

Keep in mind zram is always running and waste battery and CPU

I recommend you to set it to ~15% of the total available ram ( 110 mb in our case )
[G 2014 Android Development] devsk:
Yes, I am aware of the zram's pros and cons. I started using zram when Android wasn't even born yet (and I mean it!) and it was a pet project of Nitin Gupta known as compcache (do a google on that).

Anyways, I digress (also, showing my age here...:)). This was an experiment to see if adding swap to the device helps LMK make better decisions. It doesn't. It delays the onset somewhat but ultimately the same thing happens.

The compression ratio I am getting from zram is about 2.5 to 3, which means that I can add 200-250MB of extra real RAM by just consuming CPU at its lowest frequency (which I lowered to 384Mhz btw). That's a big boon to this 1GB device. I think gains justify the overhead incurred.

Surprisingly, I am seeing very good results from this experiment, even with dropping of the caches every 5 seconds completely. It looks like the Linux page/buffer cache pages are not being reclaimed and its preferring LMK killing tasks instead of caches getting page evictions. Which IMO is broken. IMHO, if there are pages in the page/buffer caches, they should be used for allocations instead of asking applications to exit or kill them forcibly if they don't comply. I understand the logic behind creating pressure through onLowMemory() callback in the application, but killing it when there are pages in cache which can be evicted, is just wrong.
[G 2014 Android Development] DiamondBond:
We'll I'm sorry then its still lmk being buggy :(

Thank you will see to it now :)

Hmm I'm actually using 100% zram now on my device to test it and uksm and swap at 1gb with swapiness at 80% and my device seems stable and fine :) however the battery seems a bit hit and I though it was cause of uksm but might be due to both zram and uksm...

:) yes I used zram on my Linux machines and also back when cm (version 7) was a good thing...

Okay yes there is an advantage for a 1gb device but there may be unstable side effects that we have to see too :)

Yes it is broken as it seems but google recommends the onLowMemory() call back in an app only for 512mb devices, we have around 800mb so it shouldn't be called/executed or whatever!

Thank you for your experimentation and help! :)

Sent from my XT1068
[G 2014 Android Development] devsk:
You just need to watch the zram stats for your usage pattern and see what kind of compression ratio you are getting. What I have found is that even upto 40% of total RAM, the zram is a big advantage. I wouldn't go beyond that point and certainly tune it based on my typical usage stats.
[G 2014 Android Development] luca020400:
I tried 25% zram and I had some problem

The device became "unstable"

In my previous device I worked a lot with a dev for fix zram in a y300 kernel

We do a lot of test and found that 15% is the best choice for the zram ( with 512mb ram device )

Then I do the same tests with the moto g 2014 and the results are pretty similar

Maybe a 20% zram can help with this device

Anyway I'm going to try uksm in my kernel to see if it improve "something"
[G 2014 Android Development] DiamondBond:
yeah same here, unstable zram... i would suggest 20% or even 30% if 15% worked good on your previous device, i want to try uksm aswell, back in the xplay days it was a real performance booster to have uksm, search for lupus kernel then from one of his threads look at his github repos, maybe you can pull some info in about the uksm he used, ;)
[G 2014 Android Development] devsk:
Right now, lollipop (5.0.2) has a severe memory leak issue and that's what's making zram unstable because what's being written to zram is not evictable without killing the system_server process. Killing system_server process will reboot the phone. Ever growing zram is just not sustainable, and hence unstable. But its a not zram issue. I can top out zram at 350MB and system ran for 2 days. Its when the system runs out of all free memory, that the phone hangs or reboots.

Note that if there is swap, the system will use it. This works as long as there is no system level leak.

The current leak is evident from the fact that the amount of memory you can reclaim by explicitly dropping caches is decreasing with time without any user intervention. So, for this experiment, you start all your favorite apps you will run. After some time, you have reached a steady state. Take a snapshot of /proc/meminfo after dropping the caches and you find X free pages. At this stage, if you don't do anything but just move between your loaded apps, the free memory should stay pretty much close to X if you drop caches. After several hours, the real free memory will be much smaller than X. After about 2-3 days of uptime, you are pretty much dead with LMK not reclaiming enough memory by killing apps and OOM taking over the proceedings by killing system_server.

My last experiment with my script above ran for 3 days without any issues, and then I could see that real free memory (the memory reclaimed by dropping caches) fell below 20MB and the phone just rebooted. That's the longest uptime I have had with my Moto G so far. Most of the time it used to reboot randomly after a day or 2 of uptime.
[G 2014 Android Development] metalrules321:
[MENTION=1416236]devsk[/MENTION]

Maaaaaaan !!!

I've swapped through the moto forums, and its been a pile of same issues plaguing each users. *damn*

From what I read,and understood, the issue is with google's code with 4.4 and 5.xx not being able to tolerate the ram usage, without killing it (could be wrong)

Could be the reason why I didn't felt it on 4.3

Isnt there any way to change it by mods or kernels (Big thanks to [MENTION=4725371]Pizza_Dox[/MENTION] btw for the script)

*retard question.......I know * lol

EDIT: The mods on moto g2 forum are dolts

All they do , is post lame, generic and C+V answers

*end of rant !*