[pulseaudio-discuss] Hard-coded allocation of 64 MB of memory upfront too big in some scenarios

[Lennart Poettering]

On Tue, 26.08.08 13:10, rdiezmail-pulseaudio at yahoo.de (rdiezmail-pulseaudio at yahoo.de) wrote:

> I'm compiling the client library for an embedded PowerPC target
> without shared memory or the like. In fact, the device has much less
> memory than a standard PC.
> 
> In this scenario, PA_MEMPOOL_SLOT_SIZE is set to a rather big value in pulsecore/memblock.c :
> 
> #define PA_MEMPOOL_SLOT_SIZE (64*1024)

> That causes allocation of 64 MB at once later on, before
> establishing any audio connections to the server. If you're using
> the client library's asynchronous interface to play a simple sound
> say from a file, you don't need that much memory, do you? How much
> should I go for?
> 
> That big allocation was a surprise, there's no mention of it
> anywhere in the documentation (or have I missed it?). I wish this
> value was configurable somehow, I had to modify the source code to
> reduce it.

There is no need to make this configurable. On modern operating
systems memory allocation works via overcommitting: although we
allocate this 64mb pool on startup, it is not actually used
right-away and thus does not actually consume any precious memory.

Only when a memory block from this pool is actaully used (i.e. written
to), the operating system allocates some real memory for it. If a
memory block is no longer used (i.e. its reference counter goes back
to 0), it will be pushed on a lock-free stack. The next memory block
allocation wil then receive it again.

Due to this, the 64MB is just an upper limit of how much shared memory
PA might end up using at max. It is not in any way related to how much
it will use at minimum. The part of the memory that we touch will
actually be allocated. And due to the stack that is involved we make
sure we only use the initial part of the pool and keep that dirty
instead of touching the entire pool.

Also note that you can use the "vacuum" command in pacmd to return
dirty memory back to the OS after we used it, because normally the
dirty memory is not ever returned.

That said, PA as it stands now is not exactly optimized for low-memory
situations. For example, to make memory allocation lock-free we use
"free lists" whose impact on memory is that objects are not freed
right-away but instead kept around for later, lock-free reuse.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4