OOMing on google instant search [n900]

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

Trunk
ARM
Maemo
Bug Flags:
in-testsuite ?

Details

Attachments

(1 attachment)

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.
[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.
tracking-fennec: --- → ?
Created attachment 478512 [details] [diff] [review]
Allocate cross-process layers surfaces from SyS V shm instead of /dev/shm to avoid being arbitrarily capped on maemo5/N900
Assignee: nobody → jones.chris.g
Attachment #478512 - Flags: review?(pavlov)
Can we get this triaged and review reassigned if necessary?

Updated

8 years ago
tracking-fennec: ? → 2.0b1+

Updated

8 years ago
Attachment #478512 - Flags: review?(pavlov) → review+
http://hg.mozilla.org/mozilla-central/rev/e6165002d049
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.