Closed Bug 852050 Opened 12 years ago Closed 12 years ago

Target 128MB RAM for Firefox OS

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: khu, Unassigned)

Details

A China partner is asking this feature. We are still waiting for their clear picture about how to promote this feature request into this market.
OS: Mac OS X → All
Hardware: x86 → All
If we decide we're going to try to do this, someone needs to reach out to the MemShrink team as soon as we have a decision. That's the team that are best positioned to help out with this.
How much RAM does this device have available to FFOS? For reference, our 256MB devices have a bit more than 100mb available to Gecko.
In the past, I've had the dubious honor of having to apologize to partners when we were not able to meet technical expectations that higher-ups had set. These partners felt duped, and we looked bad. I'd like to avoid that this time around. Until we know how much RAM is actually available to Gecko, it is impossible to say how feasible this is. I'd certainly appreciate if we didn't promise that we're able to ship in this configuration until we know more details and until the MemShrink team has had a chance to evaluate the situation.
(In reply to Justin Lebar [:jlebar] from comment #2) > How much RAM does this device have available to FFOS? For reference, our > 256MB devices have a bit more than 100mb available to Gecko. in 128Mb device with HVGA display. There're some memory allocated for kernel, modem...etc. We can have 60-70Mb in Gecko.
Thanks, Viral. Right now the main b2g process, which does not run any apps, takes up ~50mb of USS when it's not misbehaving. That leaves 20mb of space for apps, assuming that the B2G main process never grows in size. For reference, the homescreen app takes up about 17mb of USS. If we're OK only ever running one app at a time, and if we're OK running only simple apps, we could probably fit within this size envelope after some work. If on the other hand we want a rich experience which e.g. allows users to play music while they browse the web, that would be much more difficult. Here's the size data (measured after rebooting a unagi running a recent eng build): > root@android:/ # b2g-procrank > APPLICATION PID Vss Rss Pss Uss cmdline > b2g 109 72844K 62824K 54121K 49864K /system/b2g/b2g > Homescreen 349 40784K 30580K 21822K 17504K /system/b2g/plugin-container > (Preallocated a 513 21132K 21128K 13455K 10216K /system/b2g/plugin-container > ------ ------ ------ > 99466K 86132K TOTAL
Add more specifc request from partner. There're three kind of applications can not be killed even in 128m memory. 1.b2g 2.visiable application 3.music(mp3) playing even in background I think part 3 will be the difficult part. Shall we have any plan to keep some specific application (music in this case) alive such as giving higher OomScoreAdj to avoild being killed?
(In reply to vwang from comment #6) > I think part 3 will be the difficult part. > Shall we have any plan to keep some specific application (music in this > case) alive such as giving higher OomScoreAdj to avoild being killed? Hi Viral, Please refer to the link as below. The process with audio playing will be PROCESS_PRIORITY_BACKGROUND_PERCEIVABLE which is lower then foreground but higher to another background priorities. Is this enough? http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ProcessPriorityManager.cpp#492
DUPE of bug 929945?
Flags: needinfo?(ying.xu)
Flags: needinfo?(khu)
No, not really. But this bug isn't useful.
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(ying.xu)
Flags: needinfo?(khu)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.