27 Feb
2012
27 Feb
'12
9:59 a.m.
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: tim(a)quitte.de
To: adi(a)drcomp.erfurt.thur.de
CC: linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] memory allocation for the real time thread, opinions wanted
[Adrian Knoth]
Iain Duncan <iainduncanlists(a)gmail.com>
wrote:
Hi
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev - 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.