Nick posted some analysis of massif output on his blog. This one caught my eye because it's in my area and looks suspicious: 5.17% (67,112,960 bytes) here: mmap (syscall-template.S:82) pa_shm_create_rw (in /usr/lib/libpulsecommon-0.9.21.so) pa_mempool_new (in /usr/lib/libpulsecommon-0.9.21.so) pa_context_new_with_proplist (in /usr/lib/libpulse.so.0.12.2) ??? (in /usr/lib/libcanberra-0.22/libcanberra-pulse.so) pulse_driver_open (in /usr/lib/libcanberra-0.22/libcanberra-pulse.so) ??? (in /usr/lib/libcanberra.so.0.2.1) ??? (in /usr/lib/libcanberra.so.0.2.1) ca_context_play_full (in /usr/lib/libcanberra.so.0.2.1) ca_context_play (in /usr/lib/libcanberra.so.0.2.1) nsSound::PlayEventSound(unsigned int) (nsSound.cpp:467) from http://blog.mozilla.com/nnethercote/2010/12/09/memory-profiling-firefox-with-massif/ We may also be causing a similar allocation for every media element.
I just learned about /proc/pid/smaps. Here's what it says for the shared memory segment: 7f45943cd000-7f45983ce000 rw-s 00000000 00:10 389983 /dev/shm/pulse-shm-2515863178 Size: 65540 kB Rss: 72 kB Pss: 72 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 72 kB Referenced: 72 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB IIUC, very little (ie. 72kB) of the segment is actually being used. So it's wasting address space, but not consuming physical memory. So it's not a big problem.
It's not a big problem when there's one, but sadly my speculation about having one mapping per open audio stream turns out to be true: With 3 WebM videos playing, there's four 64MB mappings (one is the libcanberra one Nicholas found): 7ff5d29ff000-7ff5d6a00000 rw-s 00000000 00:10 1469831 /dev/shm/pulse-shm-1447529656 7ff5e1dff000-7ff5e5e00000 rw-s 00000000 00:10 1469643 /dev/shm/pulse-shm-1970121123 7ff5e73f9000-7ff5eb3fa000 rw-s 00000000 00:10 1469603 /dev/shm/pulse-shm-1485167539 7ff5ef5d2000-7ff5f35d3000 rw-s 00000000 00:10 1469436 /dev/shm/pulse-shm-102476865 In addition to using too many threads per media element (bug 592833), these large mappings will be contributing to the address space exhaustion we've seen with lots of small media files active (e.g. bug 557423). Fortunately, I think this problem will disappear post-FF4 when we switch to using PulseAudio directly, because we'll have finer control over PA's initialization and can ensure only a single mapping is created and shared for all media elements.
To be clear, the problem here lies in the alsa-pulse plugin that we're using via the ALSA API. It creates a new pa_context for every pcm opened via snd_pcm_open, but the PA API permits sharing all of this state.
(In reply to comment #2) > > Fortunately, I think this problem will disappear post-FF4 when we switch to > using PulseAudio directly, because we'll have finer control over PA's > initialization and can ensure only a single mapping is created and shared for > all media elements. Is there a bug open for this?
It's about time there was: bug 623444.
BTW, the platform for this bug is "Windows 7" -- but presumably it's a Linux-only thing?
We can't fix this until we can build and test the PulseAudio backend for libcubeb, which depends on bug 662417.
Fixed by the landing of bug 837563. Users with PA available will get the cubeb_pulse backend, which uses a single PA context and thus a single 64MB mapping. Users without PA will get the cubeb_alsa backend but won't see this issue as it's exclusive to the ALSA PA plugin.