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 copythat 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 spacesince a memory pointer is likely to be smaller than you message union. Your code canassume that when the low prio thread has put something on the ringbuffer it cannot befreed/rereused until the read index has moved past it.
Both of these methods are affectively the same, what you are trying to do is providea method that the low prio thread is responsible for both malloc and free. You can alsoreduce the amount of copies you are making although that is not a big overhead sinceyour message union is probably pretty small. If you think the RT thread is going to need these bits of message memory for more timethan the size of the ringbuffer then you could consider using pointers but passing themback 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: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [LAD] memory allocation for the real time thread, > opinions wanted > > [Adrian Knoth] > > >Iain Duncan <[email protected]> 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 > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
