Closed Bug 948828 Opened 6 years ago Closed 6 years ago

Set a hard limit for the number background processes

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED WONTFIX
blocking-b2g -

People

(Reporter: alan.yenlin.huang, Unassigned)

Details

Attachments

(1 file)

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.
Attachment #8345791 - Flags: review?(khuey)
blocking-b2g: --- → 1.3?
Whiteboard: [tarako]
Why do we need this?  Since apps would be killed for low memory, I did not get your point.
blocking-.  please discuss thinker's comment.
blocking-b2g: 1.3? → -
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?
Flags: needinfo?(ahuang)
(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.
1.3T? to keep in tarako triage radar

hi alan, can you further update this bug? thanks
blocking-b2g: - → 1.3T?
Whiteboard: [tarako]
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-
Flags: needinfo?(ahuang)
Attachment #8345791 - Flags: review?(khuey)
Cancel the review? since we should have further discussion first.
(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.
blocking-b2g: 1.3T? → -
(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.
Assignee: ahuang → nobody
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.