846065 - Tune LMK to keep larger file cache

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Michael Schwartz [:m4]]

Make the lowmemorykiller more aggressive at killing background applications to keep a larger file cache - this results in better performance.

Comment 1

[Michael Schwartz [:m4]]

Attachment: Proposed more aggressive LMK values

Comment 2

[Michael Vines [:m1] [:evilmachines]]

Some more background:  these are the values that we've been using for our stability testing for the last couple weeks and are seeing much better results there.  This also helps with subsequent app launch times as background apps are evicted sooner.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Testing with 256MB or 512MB?

Comment 4

[Michael Vines [:m1] [:evilmachines]]

256MB only.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Mozilla has done zero serious tuning of these parameters, we just pulled the values out of our butts.  (Which makes them [fill in the blank].)  My inclination is to take these wholesale.

Comment 6

[Michael Vines [:m1] [:evilmachines]]

FWIW, these numbers is our LMK expert.  That's not to say they are perfect, of course, but there was certainly some analysis done on them by somebody that knows a little more about the topic than most.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Some analysis > No analysis. Ship it!

Comment 8

[Justin Lebar (not reading bugmail)]

>-pref("hal.processPriorityManager.gonk.backgroundKillUnderMB", 8);
>+pref("hal.processPriorityManager.gonk.backgroundKillUnderMB", 20);

This is essentially a 12mb reduction in the memory that's available to background apps.  In practice, I'd expect this reduces the number of apps we can run in the bg by 1.

I'm all for increased performance, and I don't want to suggest that we should give incumbency preference to the current values, since they were arrived at with zero experimentation, but it seems there is a trade-off here, and I know our hw partners are really concerned about the number of apps we can maintain in the bg.

How much of a perf boost are you seeing with this change?

Comment 9

[Justin Lebar (not reading bugmail)]

> Some more background:  these are the values that we've been using for our stability testing for the 
> last couple weeks and are seeing much better results there.

Oh, this is interesting.  The device crashes less-often with these prefs?

It could be that these prefs leave more room for fg apps, which lets us work around the case when we have two fg processes at the same time (e.g. we launch an app while there's another process in the fg, e.g. bug 845978).

I'm happy to take this if there's a stability improvement, but can you guys sign off that you're OK with the fact that it reduces the number of bg apps we can potentially keep alive?

Comment 10

[Michael Vines [:m1] [:evilmachines]]

(In reply to Justin Lebar [:jlebar] from comment #9)
> can you guys
> sign off that you're OK with the fact that it reduces the number of bg apps
> we can potentially keep alive?

Not sure if I'm the guys that you're referring to, but yes the guys around here are happy to trade one less bg app for improved perf/stability.  


(In reply to Justin Lebar [:jlebar] from comment #8)
> How much of a perf boost are you seeing with this change?

We had those numbers somewhere, don't have them handy right now.  m4 can probably find them if you want.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2450d0d56213

Comment 12

[Justin Lebar (not reading bugmail)]

> Not sure if I'm the guys that you're referring to

I'm not sure who I'm referring to, tbh.  :)

> We had those numbers somewhere, don't have them handy right now.  m4 can probably find 
> them if you want.

Correctness trumps speed as far as I'm concerned, so I'm happy with the assertion that this improves stability.  But numbers are always interesting if you have them to share.  :)

Comment 13

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #10)
> (In reply to Justin Lebar [:jlebar] from comment #9)
> (In reply to Justin Lebar [:jlebar] from comment #8)
> > How much of a perf boost are you seeing with this change?
> 
> We had those numbers somewhere, don't have them handy right now.  m4 can
> probably find them if you want.

This isn't my own patch for once, so I'm in a position to approve without guilt.  My finger is on the button right now, but having a more quantitative idea of what we're trading off for one less background app would be nice.

Comment 14

[Michael Vines [:m1] [:evilmachines]]

(cutting out the middleman)

Comment 15

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/2450d0d56213

Comment 16

[Michael Schwartz [:m4]]

Struggling to provide more than just anecdotal evidence as the tools have been giving me grief.  The Android calculator for LMK values demands a way higher number (ie 44MB) but isn't really designed for 256MB devices.  Although the data is messed (see above re grief) these numbers appear to result in overall better launch times if the app isn't in the background.

Comment 17

[Michael Vines [:m1] [:evilmachines]]

(we can tune backgroundKillUnderMB in a follow-up bug if needed)

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/191e46b448cf
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/6a9c41cff689

Comment 19

[amiller]

Does not make sense to create a regression issue.

Comment 20

[Darren]

Cannot verify, need steps to blackbox test this issue.