1233092 - Investigate the impact of the extra memory used by Shmem objects

Status: NEW

(Core :: Graphics, defect)

Description

[Nicolas Silva [:nical]]

Don't know this code too well so I might be completely off, but looking at https://dxr.mozilla.org/mozilla-central/rev/e6463ae7eda2775bc84593bb4a0742940bb87379/ipc/glue/Shmem.cpp#422 it seems that we are allocating shmems that are the requested size (rounded up to a multiple of page size) plus a front sentinel and a back sentinel both of which are page sized.

gfx code uses separate shmems for each texture (aka video frame, front/back/on-white/on-black buffer in a tile), so the extra memory used by sentinels and the fact that shmem sections are multiples of page sizes can add up pretty quickly.

I am not sure that the back sentinel is occupying actual memory, but we do read a bit of information (such as the shmem size) from the front sentinel so the later eats more than just virtual address space.

Comment 1

[Nicolas Silva [:nical]]

Bug 1228952 should help mitigate the cases where textures are multiples of the page size and we end up allocating an extra page for the texture info (size, format, etc) by moving the latter out of the buffer.

If it turns out that the sentinel pages are expensive, bug 1128503 can help (currently the bug is filed but nobody is working on it since it's not high priority).