Lowmemorykiller is configured really high for X10III, could it use same values as 10 II?

Bug Reports
#1

REPRODUCIBILITY: Configuration issue, can be checked any time
OS VERSION: 4.4.0.68 (since introduction of 10 III)
HARDWARE: 10 III (10 II to lesser extent)
UI LANGUAGE: Any
REGRESSION: Yes, compared to Xperia 10 or earlier devices

DESCRIPTION:

So SFOS has patched device configuration provided by Sony so 10 II has 6x higher minfree values that default and 10 III has 12x higher.
In both patches it has been described that it is so Android apps don’t all get killed before any native app is killed. But I think there has been a slight misunderstanding.
All Sony devices have this line: ro.lmk.use_minfree_levels=true which means that increasing values for system-wide lmk will also increase values for the Android only lmkd. Here is relevant article from google: Low Memory Killer Daemon  |  Android Open Source Project
This all means that Android apps still get killed first, just less total RAM is used.
In another thread we discovered that reducing those values lead to over all better system responsiveness. And Android apps don’t get killed too quickly.
I have 2 suggestions then:

  1. If the values don’t actually do what expected, could they get lowered at least to Xperia 10 II levels? But I would personally remove those patches and go back to Sony’s default values, which worked well on older devices
  2. If developers of SFOS want Android apps to get killed later, maybe they should manually configure lmkd to have lower values? But then again, minfree for lmk could be lowered, as they no longer need to be that high.

Could it simply be set to the values 10 II uses, which were chosen by testing? We confirmed those values also provide the best ballance between native and Android, more RAM has nothing to do with it

ADDITIONAL INFORMATION:

Warning for people testing it
It seems like lkmd doesn’t take new values set for lowmemorykiller immediately, so for testing I manually edited /vendor/etc/init/init.lena.rc. But maybe all you need is restarting AlienDalvik.
So when booting with stock config, and then setting minfree really low I could replicate Android apps being closed and reloaded too often, but when I set them in init.lena.rc all worked fine.
Edit: Thaodan explained that lkmd doesn’t use minfree values, so I crossed out those parts. It doesn’t change the problem and solution though.

13 Likes
Community meeting on IRC 2nd February 2023
#2

I have compared default, 2x, 3x lower and now Sony default values both minfree and not setting adj). And in my opinion Sony defaults definitely work the best. When I open a dozen of apps, both native and Android, when multitasking some Android apps need to be reloaded, but they get killed much later. Which in my opinion is much better experience. So I am definitely voting for returning to Sony defaults.
Edit: Using Sony defaults I finally could replicate the original reason mentioned in the patch for raising the limits. Any Android app would get closed after a few seconds, because native apps were using so much, like browser using 30%. So I get why the limits were raised, even if I prefer that behaviour over all and could only replicate that behaviour once. I think the sweet spot is very close to the original defaults, them being 2x or 3x, and not 12x like it is now. I like how then Android apps are kind of killed, but still appear on the main screen as running, and after a bit of loading open where you finished. So it lets lkmd do its job.

3 Likes
#3

Sorry to be a bit annoying here, but it really helps if you use the bug reports template. Can you edit the first post?

otherwise, well written bug report!

1 Like
#4

I think direc85 summed it best in another topic:

Even though I still prefer behaviour with much lower values, where Android apps get killed before native, I totally get why Jolla chose values for 10 II, a ballance between Android and native.
And from our testing it seems exactly the same values work best for 10 III, and with more RAM the values don’t have to be different, which makes total sense.
So could this decision for 10 III be investigated, and maybe come back to 10 II values that were well tested?

#5

Thanks for the quote!

I would like to add that with the values in the said commit, fingerprint sensor and mpris-proxy have worked flawlessly ever since, I had one OOM kill happen with quarter-ish values. If using the X10II values seem too radical a change, it’s better to err to the safe side; the numbers I used could be considered, too.

1 Like
#6

Thanks for highlighting this @JacekJagosz and for the related investigation. I’ve logged this internally for consideration and tagged it here as “tracked”.

2 Likes