Tuning the oom killer / low memory killer

[X0X0]

Understood, and I thank you for your great help and your expertise.

Diffetence between night and day with the new values using your recommend number.

[GiT]

Gonna test&reply
10x!

[leon]

Platform: Sony Seine (Xperia 10 II)
OS: SFOS 4.4.0.72

Jolla adapted the sony values from:
15360,19200,23040,26880,34415,43737
to
92160,115200,138240,161280,206490
in 2021 and then further in 2022 to
117160,140200,163240,186280,256490
The goal was apparently to fix/improve the low memory killer.
I think it depends heavily on the individual workload.
I will revert to the first change and report it back here if it works for me …

[jenix]

With my Xperia 10 II, I more and more get the impression that the main issue is that the device simply has to few memory to run SFOS alongside multiple Android apps. Playing with the oom killer tuning I simply noticed that this only changes, which processes get killed when memory gets short. Ideally, there should be enough memory so the oom killer doesn’t have to step in in the first place.
After adding a 1GB swapfile on the /home partition, much less oom killing seems to occur, even though it still happens. This may be further enhanced by tuning the oom killer values (I’m currently using Jollas defaults). Unfortunately, since the /home partition is encrypted, I need to swapon the file after every reboot. Ideally, there may be some unused partition that could be used to increase the swap space, but I’m not familiar with the partition layout and don’t want to risk overwriting essential partitions.

Nevertheless, I think possibly the best way is to do both: give the device more ram (the internal flash storage should be relatively fast) and tune the oom killer (or revert it back to its originals).

[Seven.of.nine]

@jenix wrote: After adding a 1GB swapfile on the /home partition…

This was a wonderful idea, @jenix , how can I also do this?

And I have another idea:

What about downsizing the encrypted home partition for e.g. 2GB and creating a real swap partition on the phones memory?

Please share your ideas and comments!

[jollajo]

As flash memory wears out, after heavy usage, I wouldn’t use internal memory as swap.
I cannot say how serious this problem is, however just to be on the save side I’d rather use external SD card. This can be quickly replaced if there’s an issue.

In addition I don’t see an advantage to have a separate partition. A swap file within an existing filesystem is more flexible.

[Seven.of.nine]

@jollajo

As flash memory wears out, after heavy usage, I wouldn’t use internal memory as swap.

Absolutely correct! I didn’t think of that. Thanks for reminding me. (Now I can better understand why also Jolla didn’t it)

[jenix]

If you want to try, you can create a swap file following any guide for linux. Please be aware though that auto mounting a swap file on the encrypted /home partition via /etc/fstab does not work an will softbrick your phone on reboot! I suspect that the /home LUKS container is not unlocked at the boot stage where the system wants to swapon the file, leading to a hang during boot. As SFOS has no emergency console (to my knowledge), I know of no possibility to revert this than to reflash the phone. Speaking from personal experience…

You may be right about the potential flash wear issues. This is probably a risk you take with this approach. Given that the system uses swapfiles as last resort (as disk-based swap is usually much slower than actual ram) I think that the actual IO is limited. At least with my usage pattern, the swap is rarely used most of the time. The additional swap mostly serves to prevent the oom killer from reaping as there still is some free memory available.
It is an interesting idea placing it on a sdcard which you can simply swap in case flash wear issues occur. Giving the much slower IO rates of sdcards compared to the internal flash, I could imagine that some performance issues could arise when the system wants to use larger amount of the swapfile a once. But this are just speculations on my side, I have not (yet?) tested that.

[robang74]

@hackman238

function KillProcesses {
    echo "s1p sipBabysitter - Doing process cleanup..."
    /bin/ps aux | /bin/grep s1p | /bin/grep -v grep | /bin/awk '{print $1}' | /usr/bin/xargs /bin/kill -9
}

What about killall s1p, instead? example:

sleep 100 &
killall sleep

[Mohjive]

@jenix

As SFOS has no emergency console (to my knowledge), I know of no possibility to revert this than to reflash the phone

There’s a recovery mode, and from there you can get a shell, mount the root partition and probably edit fstab by chrooting to that mount point. If you know how to create an auto-mount, you should probably know how to undo it (or learn ).

[jenix]

Sorry, I may have been unclear there. SFOS generally has an emergency console for this cases, but at least the Xperia 10 II which I use has this feature missing, so I had no way of solving my error this way.

[smatkovi]

It has, but you have to “flash” the recovery from a computer. Actually you don’t flash it you just send it to the phone and tell it to boot it

[Seven.of.nine]

A boot manager on the phone would be really great, that asks the user to boot the phone into normal mode or into rescue mode on powering up the phone, like a linux computer has it.

Surely this could easily be implemented, because /boot/hybris-recovery.img is present on the phone.

Worth a feature request? Or possible to be implemented by the community to not demand Jollas limited resources too much?

When booting the recovery mode on the phone and using a BT keyboard, then rescue operations could be done without having a computer.

[robang74]

@Seven.of.nine

A boot manager on the phone would be really great, that asks the user to boot the phone into normal mode or into rescue mode on powering up the phone, like a linux computer has it.

Surely this could easily be implemented, because /boot/hybris-recovery.img is present on the phone.

Worth a feature request? Or possible to be implemented by the community to not demand Jollas limited resources too much?

AFAIK, the recovery image is not present on the phone but delivered into the package. Unfortunately, it seems almost useless at least on Xperia 10 II

• A list of hybris-recovery.img shortcomings

@Seven.of.nine

When booting the recovery mode on the phone and using a BT keyboard, then rescue operations could be done without having a computer.

AFAIK, no because there is no a reasonable way to deal with the display after the recovery boot, e.g. cfr. yamui part in the link above. Even the telnet IP address is shown properly.

---

More in general

• A list of hybris-recovery.img shortcomings - #13 by robang74

[MartiMasaKoegx]

Does it still makes sense to tune the OOM low memory killer for the Xperia 10 III ? I often have the Sailfish browser open among at least 4 -5 other apps. The OOM makes them to close on a daily basis. This doesn’t happen on my other SFOS devices.

[Kanthal]

How much ram do you have on the other devices that have no issues?

[MartiMasaKoegx]

There is much less RAM compared to Xperia 10 III and that’s the interesting thing. Xperia 10 puls = 4GB, Xperia XA2 ultra = 4 GB and Xperia XA2 plus = 6 GB (same as 10 III but 32bit system). Non of those older devices suffer from OOM kills as much as the 10 III.

[davidrasch]

which points to the major difference as the root cause, the introduction of 64 bit

[hennsch]

I changed the minfree values on my 10 II to what was suggested here.

/vendor/etc/init/init.seine.rc:
#write /sys/module/lowmemorykiller/parameters/minfree “117160,140200,163240,186280,256490”
write /sys/module/lowmemorykiller/parameters/minfree “58580,70100,81620,93140,128245”

That seems to help somehow, but to be honest it is super hard to tell. The moment i open more that 3-4 apps or open one big consumer like an offline mapping app i am very likely to see things falling apart quickly. If i am lucky it will just kill something that i can start again, more often it will make the whole android subsystem die and needing manual restart.
And often the device somehow gets serious hickups (whole subsystems not working anymore, maybe some core services killed?) that will require a reboot.

This is another one of these threads where a lot of good information is around, but no definitive answer or fix. The whole concept of two OOM killers that do not know about each other seems totally broken, while other information suggests that the sailfish oom mce thingy is based on the wrong input in the first place … like including buffer caches which should maybe be flushed before going around like killall -9 style.

I am currently travelling and having mapy.cz or puremaps open is normal, any attempt to use them for turn by turn navigation will likely crash the app to my whole phone …

Another way to get into trouble is opening 3+ tabs in the browser and having a second android browser running for all the websites that the stock browser can not handle. And maybe whatsapp and email.

This needs to be solved or at least explained! I am not sure i would want to buy a 10 III just to see the same bugs show there. It might have more memory but that is only going to cut it for so long. Throwing more memory on the bugs is just covering them up, not solving them!

[lkraav]

I am not sure i would want to buy a 10 III just to see the same bugs show there.

10 II and III experiences are like night and day. I tried every trick in the book on 10 II, can confidently say it cannot be rescued.

Been daily driving 10 III for 4mo, and all that aggravating soul-destroying swap slowness mostly just doesn’t happen here.

While yes, ideally software would improve, one needs to check realities with Sailfish and Jolla’s velocity. More hardware, if it works well enough, is the clear winning choice.