Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: save the memory allocation progress in the case the process is terminated from OOM #9

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

john-peterson
Copy link

todo

  • create a separate file for every hog or disable when hogs>1
  • avoid crash when local folder lack write access
  • fix mixed indentation
  • write random data to memory for realistic zram limit

realistic zram limit

this amount of compression is not realistic

dumpsys meminfo|tail
     ZRAM:   153,660K physical used for 2,373,888K in swap (2,674,468K total swap)

my phone

firefox had been crashing all day on my 4 gig phone. AppMemoryUsageActivity showed 600 meg max for firefox. i have seen 3,4 gig before. and os+ui+apps 1700 700 500 meg. this would indicate one gig left for apps don't understand why firefox was so constrained. after reboot os+ui dropped 500 each to 1200 250. despite this firefox always terminate termux. if two gig is available there should be enough for both. i suspect it's because it always goes after the heaviest app first and there are always tons of apps running

citra is also terminated around 600 meg i think although i had not tried it recently and there was no statistics for it. the next time it crashes i will check. zelda crashed before i could save. i played the same stretch three times before i gave up. that was even after a fresh boot

in android 13 gradle aide eggns firefox has been able to overcome the oom fail safe and hang the system. forced me to hold down the power button for ten seconds and pray that no system file is left in a dirty state and force a factory reset. it required a data wipe once after a failed update lost all files

i eventually braved to rsync everything to removable sd card and stress test my phone. it got to 2700 meg less than emulator when swap was enabled. 1000 less than total memory

rsync /sdcard/ /storage/4A21-0000/ -av

stress -m 1 --vm-no-spin --vm-stride 64 --vm-bytes 4g
stress: info: [5754] Previous run was able to write 2479m before termination

notice that running it slower can make a big difference. this is another run with default strides

stress --vm-no-spin --vm-bytes 4g -m 1
stress
stress: info: [6059] Previous run was able to write 1619m before termination

android emu test

with 75% zram the emu reached 1400 meg more than physical total. in one manual reading while running it had one gig in zram with ten times compression

avdmanager create avd --package "system-images;android-34;google_apis;x86_64" --abi "x86_64" --device 46 --name nexus

emulator -writable-system -no-window -memory 3600 -noaudio -avd nexus -qemu "-vnc :0"

nano /vendor/etc/fstab*
/dev/block/zram0 none swap defaults zramsize=75%

meminfo dumpsys
Total RAM: 3,514,764K (status normal)
3,584K in swap (2,608,852K total swap)

stress -m 1 --vm-no-spin --vm-stride 64 --vm-bytes 8g
stress: info: [4143] Previous run was able to write 5253m before termination

pidof stress
cat /proc/5264/status|grep -E "VmHWM|Swap"

VmHWM:   2680220 kB
VmSwap:  1297040 kB

without swap it reached 1300 short of total. as a comparison Ubuntu+earlyoom without zram will be able to offer 900 meg more and stop 400 meg short of total ram

emulator -writable-system -no-window -memory 4000 -noaudio -avd nexus -qemu "-vnc :0"

swapoff /dev/block/zram0

stress -m 1 --vm-no-spin --vm-bytes 4g
stress
stress: info: [8825] Previous run was able to write 2759m before termination

from adb shell lmk failed to kill stress. it was able to get 500 meg higher but stalled the system

stress -m 1 --vm-no-spin --vm-bytes 4g
stress
stress: info: [4200] Previous run was able to write 3281m before termination

diff phone emu

this is directly after stress has killed everything it can. usage is 1400 higher on the phone.

400 in the kernel. any hunch what that might be related to? i would like to print the same thing in Ubuntu. especially kernel memory usage excluding caches. it seems to come from MemInfoReader.java

what is the system process? is it unique to android?

adb shell dumpsys meminfo>phone.mem

tail -10 emu.mem |grep -E "Total|Free|Used"
Total RAM: 3,918,220K (status normal)
 Free RAM: 2,499,846K (  778,034K cached pss + 1,334,916K cached kernel +   386,896K free)
 Used RAM: 1,387,155K (1,119,963K used pss +   267,192K kernel)
 
tail -10 phone.mem |grep -E "Total|Free|Used"
Total RAM: 3,553,360K (status normal)
 Free RAM: 1,080,192K (  434,556K cached pss +   533,780K cached kernel +   111,856K free)
 Used RAM: 2,832,600K (2,119,392K used pss +   713,208K kernel)

roughly 500 is higher usage in common apps. com.android.systemui is never killed by lmk but can be killed manually to restore memory . leaks are difficult to find

sed -n "/PSS by process/,/PSS by OOM/p" emu.mem>emu.pss
sort -k2 emu.pss>emu.sort

join -j2 phone.sort emu.sort|sort -rnk2
com.android.systemui 364,628K: (pid 2857) 84,580K: (pid 726)
system 309,295K: (pid 1517) 188,743K: (pid 515)
com.google.android.inputmethod.latin 165,758K: (pid 10150) 74,667K: (pid 1310)
surfaceflinger 139,700K: (pid 1322) 24,893K: (pid 392)

roughly 500 is 60 more programs running on the phone. 129 unique for the phone. a "pm disable/enable" script might be able to disable some programs that are rarely used. com.google.android.apps.messaging can not be disabled

wc phone.pss
    192     771    8754
wc emu.pss
    134     535    6701
awk 'NR==FNR {d[$2];next} ! ($2 in d) {print}' emu.pss phone.pss|wc
    129     522    6224

awk 'NR==FNR {d[$2];next} ! ($2 in d) {print}' emu.pss phone.pss|head
     70,683K: com.google.android.apps.messag
ing (pid 10281)
     63,165K: com.android.launcher3 (pid 873
4 / activities)
     53,350K: android.hardware.camera.provid
[email protected]_64 (pid 1254)
     51,791K: com.android.vending:background
 (pid 12134)
     45,306K: com.google.android.apps.messag
ing:rcs (pid 10074)
     42,203K: zygote (pid 1108)
     37,148K: com.google.android.gms.unstabl
e (pid 12981)

com.android.settings is kept alive by a receiver that is not in the emulator or the source

https://android.googlesource.com/platform/packages/apps/Settings

dumpsys activity services|grep settings intent={cmp=com.android.settings/.wifi.WifiSettingsReceiver$WifiStateService}

proposed aosp patches

when writing this i came up with these proposals for android

  • allow localhost debugging if there is no wifi network. it is frustrating and pointless to be disconnected from localhost adb just because the wifi goes out

  • read the memory cleanup api in lmk. i have excluded termux from memory cleaning in settings. lmk could read this and try to kill termux last when there is no other left

  • real memory boost mode in memory settings that disable as many system features as possible. it should be possible to bring every device to the same minimum as the emulator image

these ideas are probably going to stay that way

  • lmk debug to file for access without adb. setprop ro.lmk.debug_file /data/data/com.termux../home/lmk.log

  • create a new permission that includes all adb permissions pm grant com.termux android.permission.DEBUG. termux never need to use adb

…erminated on Out Of Memory and print it on the next run

anything can happen when testing the memory limit including losing the entire shell. this will save progress to disk while trying to write to large amounts of memory
@john-peterson john-peterson changed the title WIP: save the memory allocation progress in the case the process is t… WIP: save the memory allocation progress in the case the process is terminated Aug 14, 2024
@john-peterson john-peterson changed the title WIP: save the memory allocation progress in the case the process is terminated WIP: save the memory allocation progress in the case the process is terminated from OOM Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant