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)

x86
Linux
defect
Not set
normal

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.
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.
Summary: Excessively large mmapped region created by PulseAudio → Excessively large mmapped regions created by PulseAudio for each active stream
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?
OS: Windows 7 → Linux
Depends on: cubeb
We can't fix this until we can build and test the PulseAudio backend for libcubeb, which depends on bug 662417.
Depends on: 662417
No longer depends on: 662417
Depends on: 837563
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
Assignee: nobody → kinetik
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.