[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: memory footprint of pulseaudio



Mail Lists wrote:
>   Running top - pulseaudio occupies 500 MiB - seems a little large to me
> - resident is less. Machine has been up for 2 days.

Presumably you mean the “VIRT” column, then?

That measures how much virtual memory address space PulseAudio is using.
Virtual memory addresses can be used in a number of ways beyond simply
mapping physical memory on a one-to-one basis.

The VIRT column has its uses, but measuring the memory footprint of a
random application is rarely one of them.

What I understand happens with PulseAudio is this: every client and the
PulseAudio daemon tell the kernel to reserve a 64 MB pool of address
space each. The kernel doesn’t allocate any real (physical) memory for
these yet.

The various programs then share their 64 MB pools with the PulseAudio
daemon, and use 64 K memory blocks (out of the appropriate pool) to
communicate. Those do need real memory behind them, but the kernel will
only actually allocate real memory in units of 4K (one page) when the
programs actually start using that memory. So you can have a 64 MB pool
which only needs 4K of physical memory!

Those 64 MB virtual memory pools add up, and are counted under the VIRT
column. But they don’t use nearly that much real memory. They don’t use
any swap space, either, unless you have configured your kernel to use
strict overcommit protection.

See 
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-August/002255.html
and related posts for more details.

Hope this helps,

James.

-- 
E-mail:     james@ | 'Short for "Sic Transit Gloria Humanorum", which is Latin
aprilcottage.co.uk | for "There goes the neighbourhood!"'
                   |     -- Menno Willemse


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]