Last Comment Bug 617852 - Excessively large mmapped regions created by PulseAudio for each active stream
: Excessively large mmapped regions created by PulseAudio for each active stream
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: x86 Linux
: -- normal with 3 votes (vote)
: mozilla28
Assigned To: Matthew Gregan [:kinetik]
:
: Maire Reavy [:mreavy]
Mentors:
Depends on: cubeb 837563
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-08 19:52 PST by Matthew Gregan [:kinetik]
Modified: 2013-11-03 13:56 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Matthew Gregan [:kinetik] 2010-12-08 19:52:48 PST
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 Nicholas Nethercote [:njn] 2011-01-05 17:29:57 PST
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.
Comment 2 Matthew Gregan [:kinetik] 2011-01-05 17:42:25 PST
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.
Comment 3 Matthew Gregan [:kinetik] 2011-01-05 17:55:25 PST
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 Nicholas Nethercote [:njn] 2011-01-05 19:51:47 PST
(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?
Comment 5 Matthew Gregan [:kinetik] 2011-01-05 19:59:00 PST
It's about time there was: bug 623444.
Comment 6 Nicholas Nethercote [:njn] 2011-01-05 20:02:57 PST
BTW, the platform for this bug is "Windows 7" -- but presumably it's a Linux-only thing?
Comment 7 Doug Turner (:dougt) 2011-02-02 15:55:20 PST
*** Bug 631058 has been marked as a duplicate of this bug. ***
Comment 8 Matthew Gregan [:kinetik] 2012-06-04 19:06:54 PDT
We can't fix this until we can build and test the PulseAudio backend for libcubeb, which depends on bug 662417.
Comment 9 Matthew Gregan [:kinetik] 2013-11-03 13:49:20 PST
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.

Note You need to log in before you can comment on or make changes to this bug.