599562 - OOMing on google instant search [n900]

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Go google.com, make sure using instant version
 (2) Type two characters into input box
 (3) Pan around a bit

Pretty soon, the content process dies from an allocation failure.  Log of allocations coming up.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

[1930] ALLOC 800 x 480 (x2!)
          8888
[1930]   DESTROY 800 x 480
[1930] ALLOC 800 x 480 (x2!)
          8888
[1914]   DESTROY 800 x 480
[1930] ALLOC 1200 x 1004 (x2!)
          8888
[1930]   DESTROY 800 x 480
[1914]   DESTROY 800 x 480
[1930] ALLOC 1600 x 2458 (x2!)
          8888
[1930]   DESTROY 1200 x 1004
[1914]   DESTROY 1200 x 1004
[1930] ALLOC 1600 x 4000 (x2!)
          8888

Here's what this translates into.  Total /dev/shm usage is in between each line.

 content                     chrome
--------------------------  ------------------
 +++ 800 x 480 x 2 (x2)
                         3072000
 --- 800 x 480 x 2
                         1536000
 +++ 800 x 480 x 2 (x2)
                         4608000
                             --- 800 x 480 x 2
                         3072000
 +++ 1200 x 1004 x 2 (x2)
                        12710400
 --- 800 x 480 x 2
                        11174400
                             --- 800 x 480 x 2
                         9638400
 +++ 1600 x 2458 x 2 (x2)
                        41100800
 --- 1200 x 1004 x 2
                        36281600
                             --- 1200 x 1004 x 2
                        31462400
 fail +++ 1600 x 4000 x 2 (x2)
      (would have been) 82662400

Two very bad things are happening.  First, for some reason we're using 8-8-8-8 surfaces on google.com, rather than 5-6-5.  I'll look into why that's happening.

Second, we try to make an allocation that would take our total /dev/shm usage up to ~80MB ... but the /dev/shm tmpfs is only 64MB on my system :S.  That really sucks: the n900 has 1GB of virtual memory!

There's low-hanging fruit with going 8888->565 (probably possible) and fixing some inefficiency in the allocation pattern here.  But we're going to run up against a 64MB limit for layers surfaces again and again.  I'll think about this some.  Our options for b1 are to switch to SysV shmem, which I'm pretty sure is allocated from a different pool, or switch back to X compositing.

Needs to block b1.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Allocate cross-process layers surfaces from SyS V shm instead of /dev/shm to avoid being arbitrarily capped on maemo5/N900

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Can we get this triaged and review reassigned if necessary?

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://hg.mozilla.org/mozilla-central/rev/e6165002d049