886278 - [System] Optimize the application priorities and scores for OOM and LMK on 512mb devices

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P2)

Description

[leo.bugzilla.gecko]

Currently, the priorities and scores defined in b2g.js file are optimized for the device which has 256MB memory. 
But, now we are getting more devices which have 512MB memory.
We think it's the right time to check the parameters are good enough for the 512MB devices.

Comment 1

[Jinho Hwang [:jeffhwang]]

Actually, I discussed about it with AHuang here in Taiwan today.
We both agree to check the effectiveness of the parameters, the application priority, score and size of memory, for OOM an LMK especially for the device has 512MB memory.
AHuang, do you have any experimental plan for this?

Comment 2

[Justin Lebar (not reading bugmail)]

Once we figure out what params we want (if we do want different params than what we have now), I think we should design the system so that Gecko looks at how much RAM is on the system and picks one set of params or another.

The alternative is to have separate configuration files for different devices, but then we have to manage all of these different files.  I'd rather have Gecko do it for us.

Comment 3

[Alex Keybl [:akeybl]]

comment 2 may be a good path forward for the future, but since we can only tweak values right now this would be Part of Vendor Build.

Comment 4

[Justin Lebar (not reading bugmail)]

If we put this in vendor builds, we will essentially not be able to debug these values on the Mozilla side, and we'll observe different memory usage characteristics on our builds than in the official builds.  That would be a pretty bad situation for us to be in; I would like to avoid it if at all possible.

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Justin Lebar [:jlebar] from comment #4)
> If we put this in vendor builds, we will essentially not be able to debug
> these values on the Mozilla side, and we'll observe different memory usage
> characteristics on our builds than in the official builds.  That would be a
> pretty bad situation for us to be in; I would like to avoid it if at all
> possible.

If that ends up being the case, we'll reconsider from our end. For now, we can assume lowest risk fix.

Comment 6

[Justin Lebar (not reading bugmail)]

Comment 4 is a hypothetical only insomuch as we make these changes in partner builds.  If we do, then it is not hypothetical in any way.

I'm trying to say that changing these values in partner builds is risky to our ability to our ability to test devices.  It is not a low-risk change.

Would you mind clarifying a point of order for me?  Who should determine how risky a change is -- engineering, or release drivers?

Comment 7

[Wayne Chang [:wchang]]

Triage - Partner would not take risky patches at this stage. Please renominate if a proposed patch is available at low risks.

Leo-

Comment 8

[Justin Lebar (not reading bugmail)]

I want to be explicit that as the owner of this code, I consider changing these values in the partner repository only to be a very risky change.  This is because it would diverge Mozilla and the partner's repositories in a significant way.

I explicitly disagree with comment 5, which argues that this is merely a hypothetical risk that we can ignore for now and that changing in the partner repository is the lowest-risk option available to us.  I do not believe we can safely ignore this risk, and I do not believe that changing in the partner build is the lowest-risk option available to us.

Comment 9

[Alex Keybl [:akeybl]]

(In reply to Justin Lebar [:jlebar] from comment #8)
> I want to be explicit that as the owner of this code, I consider changing
> these values in the partner repository only to be a very risky change.  This
> is because it would diverge Mozilla and the partner's repositories in a
> significant way.

It looks like this isn't the case, as the bug is now leo-

> I explicitly disagree with comment 5, which argues that this is merely a
> hypothetical risk that we can ignore for now and that changing in the
> partner repository is the lowest-risk option available to us.  I do not
> believe we can safely ignore this risk, and I do not believe that changing
> in the partner build is the lowest-risk option available to us.

I didn't intend to overreach. I could have simply noted that timelines need to be taken into consideration, and a new per-device solution sounded like late architectural change.

Comment 10

[Gabriele Svelto [:gsvelto] (PTO)]

I had some time to briefly look at this bug when I was in Taipei two weeks ago and I toyed with a patch that used a very simple approach to solve this issue: I tried turning all the values of the lowmemkiller thresholds as well as the low memory notification trigger into percentages of PR_GetPhysicalMemorySize() so that on 256MiB they would yield the same results as the absolute values and proportionately larger ones [*] for 512MiB devices.

While playing with it I realized however that this might not be the best approach because as the available memory increases you don't want certain thresholds to go above a certain level. For example a low-memory trigger which notifies applications when there's still 100MiB of free memory doesn't make any sense.

Similarly we have a number of other parameters that we've specifically tweaked for the first release that we might want to adjust but not necessarily proportionally. Certain ones would benefit from a one-time increase while others might be proportional but would still be better behaved with a cap to prevent them from being too large. To name a few we have (with current values):

browser.cache.memory.capacity   1 MiB
image.cache.size                1 MiB
image.mem.max_decoded_image_kb 30 MiB
canvas.image.cache.limit       10 MiB
media.cache_size                4 MiB

Additionally we've tweaked a bunch of GC parameters under javascript.options.mem.* as well as buffer sizes and number of connections under network.buffer.* and network.http.*.

Considering the amount of parameters and the potential complexity of their interactions it might be worth to first establish what "good" parameters would be for a 512MiB device and then introduce a system to implement them without having to tweak the configuration on a per-device basis (percentage of total memory + caps sounds like a good approach to me but I'd like to hear others' options about it).

[*] Note that this wouldn't yield doubled values because PR_GetPhysicalMemorySize() gives us ~180MiB on 256MiB devices but almost ~400MiB on the 512MiB ones due to the differences in kernel size and similar effects.

Comment 11

[Mike Lee [:mlee]]

Wander, this bug includes some of what we discussed today re: having different b2g.js. Jeff Hwang filed this a while back

Comment 12

[BMO Automation]

Firefox OS is not being worked on