[pulseaudio-discuss] [PATCH 2/2] pulsecore: srbchannel: Introduce per-client SHM files
Ahmed S. Darwish
darwish.07 at gmail.com
Sat Aug 29 12:09:40 PDT 2015
On 2015-08-28 02:58PM +0200, David Henningsson wrote:
> On 2015-08-28 14:48, Ahmed S. Darwish wrote:
> > The PA daemon currently uses a system-wide SHM file for all clients
> > sending and receiving commands using the srbchannel low-latency
> > mechanism.
> > To be able to safely run PA daemon in system mode later using memfds,
> > and to provide the necessary ground work for policy and sandboxing,
> > create the srbchannel SHM files on a per-client basis.
> > Signed-off-by: Ahmed S. Darwish <darwish.07 at gmail.com>
> Looks good as a start, but notice that this will not fix security, as the
> audio is still routed over the ordinary mempool.
> Would be interesting to know how this affects memory usage though.
OK, I've done some memory benchmarks using the shell+procfs+gnuplot
scripts I've posted here:
Basically, PA daemon VmSize and Dirty_Private/Shared size (dirty RSS)
usage is sampled while increasing the number of connected `paplay'
clients over time. Here is the png chart:
To summarize, by connecting __30__ paplay clients to the daemon,
this per-client SHM patch introduced the following memory effects:
- Increased the daemon VmSize from 2.3 GiB to 4.2 GiB
- Almost maintained the dirty RSS usage, with a slight increase
from 34.3 MiB to 36 MiB
The dirty RSS increase is negligible given the high number of
connected clients, but the _virtual_ memory size increase is huge,
limiting 32-bit architectures to around 24 clients maximum.
Given these numbers, especially regargding VmSize, what do you
More information about the pulseaudio-discuss