<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<div><font face="Times New Roman" size="2" style="font-size:10pt;">Hi Iain,</font></div><div><font face="Times New Roman" size="2" style="font-size:10pt;"><br id="FontBreak"></font>Can you use any alternatives such as:</div><div><br></div><div>a. Don't malloc/memcpy space for these messages in the RT thread - just use the copy</div><div>that is on the ringbuffer and move the write pointers when you have used the message.</div><div><br></div><div>b. Just write memory pointers on to the ringbuffer: this gives you quite a lot more space</div><div>since a memory pointer is likely to be smaller than you message union. Your code can</div><div>assume that when the low prio thread has put something on the ringbuffer it cannot be</div><div>freed/rereused until the read index has moved past it.<br><br>Both of these methods are affectively the same, what you are trying to do is provide</div><div>a method that the low prio thread is responsible for both malloc and free. You can also</div><div>reduce the amount of copies you are making although that is not a big overhead since</div><div>your message union is probably pretty small.</div><div><br></div><div>If you think the RT thread is going to need these bits of message memory for more time</div><div>than the size of the ringbuffer then you could consider using pointers but passing them</div><div>back from the RT thread over another ringbuffer when you no longer need them.</div><div><br></div><div>Regards, nick<br>"at the end of the day its nil nil at half time”.<br>Trevor Brooking<br><br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Mon, 27 Feb 2012 09:38:34 +0100<br>> From: tim@quitte.de<br>> To: adi@drcomp.erfurt.thur.de<br>> CC: linux-audio-dev@lists.linuxaudio.org<br>> Subject: Re: [LAD] memory allocation for the real time thread, opinions wanted<br>> <br>> [Adrian Knoth]<br>> <br>> >Iain Duncan <iainduncanlists@gmail.com> wrote:<br>> ><br>> >Hi<br>> ><br>> >>- I could pre-allocate a giant list of messages and pluck the data off<br>> >>that<br>> >>list when I need to make a new one<br>> >>- I could pre-allocate a block of memory and allocate off that<br>> ><br>> >I'm writing from my phone, so for the sake of brevity, I will only <br>> >talk about one option you might have missed:<br>> ><br>> >Google for "A Study in Malloc: A Case of Excessive Minor Faults - USENIX" by Ezolt.<br>> ><br>> >You can instruct your malloc implementation to operate on a <br>> >previously allocated (and prefaulted) memory pool. free() will then <br>> >never return the memory to the OS, but back to this memory pool.<br>> ><br>> >This way, if you have a rough estimation for your overall memory <br>> >requirements, you simply allocate it once in a non-real-time context <br>> >and then use malloc/free at will.<br>> <br>> This, I'm afraid, is an idea with a fair share of issues. It does not <br>> seem a trivial problem to estimate the total memory needs of a <br>> reasonably complex application. And even if you can solve this, you <br>> will find that common malloc implementations (such as the one in <br>> glibc) protect the heap with mutexes. Regardless of memory <br>> availability, your real-time thread can always stall in malloc() or <br>> free() when a heap mutex is found locked by another thread.<br>> <br>> As for the original question, I'd suggest handling the maintenance and <br>> memory management of large lists of events in low-priority, <br>> low-frequency threads. These threads periodically feed the realtime <br>> thread bursts of a small number of events, ahead of time and using <br>> preallocated FIFO queues which can be of reasonably modest size. (In <br>> fact, I seem to remember that this approach has been discussed on this <br>> list recently, if perhaps briefly.)<br>> <br>> Cheers, Tim<br>> _______________________________________________<br>> Linux-audio-dev mailing list<br>> Linux-audio-dev@lists.linuxaudio.org<br>> http://lists.linuxaudio.org/listinfo/linux-audio-dev<br></div></div> </div></body>
</html>