WIP: save the memory allocation progress in the case the process is terminated from OOM #9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
todo
realistic zram limit
this amount of compression is not realistic
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
notice that running it slower can make a big difference. this is another run with default strides
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
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
from adb shell lmk failed to kill stress. it was able to get 500 meg higher but stalled the system
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?
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
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
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
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