[pulseaudio-discuss] [PATCH 2/2] pulsecore: srbchannel: Introduce per-client SHM files

[Ahmed S. Darwish]

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:

     http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/24002

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:

     http://darwish.chasingpointers.com/pub/pulse-memory-usage-29082015.png

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
think?

Thanks,

-- 
Darwish
http://darwish.chasingpointers.com