948828 - Set a hard limit for the number background processes

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Alan Huang]

As I referenced some other mobile platform, like android and WP before WM7, etc., they usually set a hard limit for the number background processes. 

The first thing came into my mind is to reuse the number of background process LRU pool's size as our hard limit. This size will be calculated with the number of background process LRU pool levels defined in b2g.js as a parameter, just like what we did for the number of background process LRU pool's size. We can also add a preference in b2g.js to enable/disable the hard limit.

I believe low ram device like Tarako and low end device like Fugu will benefit from this.

Comment 1

[Alan Huang]

Attachment: Implement an Out Of Background Process killer, v1

Comment 2

[Thinker Li [:sinker]]

Why do we need this?  Since apps would be killed for low memory, I did not get your point.

Comment 3

[Tony Chung [:tchung]]

blocking-.  please discuss thinker's comment.

Comment 4

[Thinker Li [:sinker]]

Alan and me had a discussion two weeks ago offline.  I think the number of the overhead of killing processes is required here to make a decision.  The problem trying to be resolved here seems like the thrashing issue I had mentioned in bug 945174, at least for 128MB and partly.  So, Alan could you provide more information before going further?

Comment 5

[Alan Huang]

(In reply to Tony Chung [:tchung] from comment #3)
> blocking-.  please discuss thinker's comment.

As I discussed with thinker on last Friday, I will apply this on Fugu (256MB, not 128MB) first to see how much we could benefit from this.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

1.3T? to keep in tarako triage radar

hi alan, can you further update this bug? thanks

Comment 7

[Alan Huang]

According to my preliminary result, we don't actually benefit from this on tarako but fugu. (Browser first launch time)

I compared 3 sets, with and without this patch: fugu, fugu with 128 MB and buri. I don't see we can benefit from this on fugu with 128 MB. I see better Browser first launch time and performance on Buri (launch from a short cut of already logged in Facebook or Yahoo). This also found on Fugu, but I can aware the other apps have worse second launch time on Fugu.

I will say this is 1.3T-

Comment 8

[Alan Huang]

Cancel the review? since we should have further discussion first.

Comment 9

[bhavana bajaj [:bajaj]]

(In reply to Alan Huang [:ahuang] from comment #7)
> According to my preliminary result, we don't actually benefit from this on
> tarako but fugu. (Browser first launch time)
> 
> I compared 3 sets, with and without this patch: fugu, fugu with 128 MB and
> buri. I don't see we can benefit from this on fugu with 128 MB. I see better
> Browser first launch time and performance on Buri (launch from a short cut
> of already logged in Facebook or Yahoo). This also found on Fugu, but I can
> aware the other apps have worse second launch time on Fugu.
> 
> I will say this is 1.3T-

Not blocking in that case.

Comment 10

[Alan Huang]

(In reply to Alan Huang [:ahuang] from comment #8)
> Cancel the review? since we should have further discussion first.

After a discussion with Thinker a few months ago, we are not going to do this. Set WONTFIX on this bug.