Hi Iain,

Can you use any alternatives such as:

a. Don't malloc/memcpy space for these messages in the RT thread - just use the copy
that is on the ringbuffer and move the write pointers when you have used the message.

b. Just write memory pointers on to the ringbuffer: this gives you quite a lot more space
since a memory pointer is likely to be smaller than you message union. Your code can
assume that when the low prio thread has put something on the ringbuffer it cannot be
freed/rereused until the read index has moved past it.

Both of these methods are affectively the same, what you are trying to do is provide
a method that the low prio thread is responsible for both malloc and free. You can also
reduce the amount of copies you are making although that is not a big overhead since
your message union is probably pretty small.

If you think the RT thread is going to need these bits of message memory for more time
than the size of the ringbuffer then you could consider using pointers but passing them
back from the RT thread over another ringbuffer when you no longer need them.

Regards, nick
"at the end of the day its nil nil at half time”.
Trevor Brooking


> Date: Mon, 27 Feb 2012 09:38:34 +0100
> From: tim@quitte.de
> To: adi@drcomp.erfurt.thur.de
> CC: linux-audio-dev@lists.linuxaudio.org
> Subject: Re: [LAD] memory allocation for the real time thread, opinions wanted
>
> [Adrian Knoth]
>
> >Iain Duncan <iainduncanlists@gmail.com> wrote:
> >
> >Hi
> >
> >>- I could pre-allocate a giant list of messages and pluck the data off
> >>that
> >>list when I need to make a new one
> >>- I could pre-allocate a block of memory and allocate off that
> >
> >I'm writing from my phone, so for the sake of brevity, I will only
> >talk about one option you might have missed:
> >
> >Google for "A Study in Malloc: A Case of Excessive Minor Faults - USENIX" by Ezolt.
> >
> >You can instruct your malloc implementation to operate on a
> >previously allocated (and prefaulted) memory pool. free() will then
> >never return the memory to the OS, but back to this memory pool.
> >
> >This way, if you have a rough estimation for your overall memory
> >requirements, you simply allocate it once in a non-real-time context
> >and then use malloc/free at will.
>
> This, I'm afraid, is an idea with a fair share of issues. It does not
> seem a trivial problem to estimate the total memory needs of a
> reasonably complex application. And even if you can solve this, you
> will find that common malloc implementations (such as the one in
> glibc) protect the heap with mutexes. Regardless of memory
> availability, your real-time thread can always stall in malloc() or
> free() when a heap mutex is found locked by another thread.
>
> As for the original question, I'd suggest handling the maintenance and
> memory management of large lists of events in low-priority,
> low-frequency threads. These threads periodically feed the realtime
> thread bursts of a small number of events, ahead of time and using
> preallocated FIFO queues which can be of reasonably modest size. (In
> fact, I seem to remember that this approach has been discussed on this
> list recently, if perhaps briefly.)
>
> Cheers, Tim
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev