Closed Bug 846065 Opened 9 years ago Closed 9 years ago

Tune LMK to keep larger file cache

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:tef+, firefox20 wontfix, firefox21 wontfix, firefox22 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-b2g tef+
Tracking Status
firefox20 --- wontfix
firefox21 --- wontfix
firefox22 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: mschwart, Assigned: mschwart)

Details

(Whiteboard: QARegressExclude, [qa-])

Attachments

(1 file)

Make the lowmemorykiller more aggressive at killing background applications to keep a larger file cache - this results in better performance.
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.
Testing with 256MB or 512MB?
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.
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.
Some analysis > No analysis. Ship it!
>-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?
> 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?
Attachment #719226 - Flags: review?(justin.lebar+bug) → review+
(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.
> 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.  :)
(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.
Flags: needinfo?(mvines)
(cutting out the middleman)
Flags: needinfo?(mvines) → needinfo?(mschwart)
https://hg.mozilla.org/mozilla-central/rev/2450d0d56213
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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.
Flags: needinfo?(mschwart)
(we can tune backgroundKillUnderMB in a follow-up bug if needed)
blocking-b2g: tef? → tef+
Does not make sense to create a regression issue.
Flags: in-moztrap-
Whiteboard: QARegressExclude
Cannot verify, need steps to blackbox test this issue.
Whiteboard: QARegressExclude → QARegressExclude, [qa-]
You need to log in before you can comment on or make changes to this bug.