Closed
Bug 617852
Opened 14 years ago
Closed 11 years ago
Excessively large mmapped regions created by PulseAudio for each active stream
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: kinetik, Assigned: kinetik)
References
Details
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.
Comment 1•13 years ago
|
||
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.
Assignee | ||
Comment 2•13 years ago
|
||
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.
Assignee | ||
Updated•13 years ago
|
Summary: Excessively large mmapped region created by PulseAudio → Excessively large mmapped regions created by PulseAudio for each active stream
Assignee | ||
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
(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?
Assignee | ||
Comment 5•13 years ago
|
||
It's about time there was: bug 623444.
Comment 6•13 years ago
|
||
BTW, the platform for this bug is "Windows 7" -- but presumably it's a Linux-only thing?
Assignee | ||
Updated•13 years ago
|
OS: Windows 7 → Linux
Assignee | ||
Comment 8•12 years ago
|
||
We can't fix this until we can build and test the PulseAudio backend for libcubeb, which depends on bug 662417.
Depends on: 662417
Assignee | ||
Comment 9•11 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Assignee: nobody → kinetik
Target Milestone: --- → mozilla28
You need to log in
before you can comment on or make changes to this bug.
Description
•