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
