Excessively large mmapped regions created by PulseAudio for each active stream

RESOLVED FIXED in mozilla28

Status

()

Core
Audio/Video
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: kinetik, Assigned: kinetik)

Tracking

Trunk
mozilla28
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

7 years ago
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.
(Assignee)

Comment 2

7 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

7 years ago
Summary: Excessively large mmapped region created by PulseAudio → Excessively large mmapped regions created by PulseAudio for each active stream
(Assignee)

Comment 3

7 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.
(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

7 years ago
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?
(Assignee)

Updated

7 years ago
OS: Windows 7 → Linux
(Assignee)

Updated

7 years ago
Depends on: 623444

Updated

7 years ago
Duplicate of this bug: 631058
(Assignee)

Comment 8

5 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)

Updated

5 years ago
No longer depends on: 662417
(Assignee)

Updated

5 years ago
Depends on: 837563
(Assignee)

Comment 9

4 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
Last Resolved: 4 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.