Thank you for the suggestions and corrections, @karry and @thigg! I’ll review and update the first post tomorrow.
That was quite an interesting read, karry! It looks like you tackled this before than me, and with more technical approach, too!
It is indeed an Android user-space daemon (that much I did get right) but I assumed it was running on the Sailfish OS side covering the whole system, because of SFOS is running on top of AOSP and that made all the sense to me. Should have checked though. The process
lmkd is running only when the Android app support is running, so that indeed is the case.
That means my impression of setting lower values to the minfree file affecting e.g. Browser is 100% placebo. I guess the increased overall responsiveness just carried over. Edit: This also means Email and Browser simply vanishing on me is not because of oom but another bugs altogether. Oh dear.
However, this means that there’s no SFOS side user-space daemon to handle oom. (Or is there? I found nothing when I searched…) Having two oom daemons monitoring the same RAM space doesn’t really sound welcoming either. Perhaps something simple like only using earlyoom SFOS-side with system application oom score adjustment could work? The in-kernel oom killer doesn’t get a lot of praises, from what I’ve read…
Indeed, I didn’t really understand vm.swappiness; it doesn’t mean what I think it did. After reading the excellent blog post, I think 25 is a good value for SFOS configuration. I’m going to keep using 50 still, as I simply prefer swapping over killed processes, and changing swappiness from 25 to 50 isn’t that drastic. The value goes up to 200 after all. There’s a lot of inactive stuff to page out, specially with 6GiB of applications loaded.
Then again, in another thread there’s someone with a swappiness of 60, but it’s a community port, and I guess swappiness value just wasn’t ever checked or considered.