In developing a frame grabbing application under QNX 6.2.0,
one architectual choice is to have the FG deliver the
image straight into a piece of memory previously mmapp’ed
and passed to the driver to use.
(One process, lots of threads).
After use, the memomry will me unmmapp’ed,
and the process will start again. Many of these
cycles will happen.
As I understand it, malloc’ed memory is not re-used
when free’ed until the process ends (or it the thread?).
So in a scenario like the above, if you did a lot
of malloc/free, you could potentially run oout of memory.
Do I have the malloc/free story straight?
In developing a frame grabbing application under QNX 6.2.0,
one architectual choice is to have the FG deliver the
image straight into a piece of memory previously mmapp’ed
and passed to the driver to use.
(One process, lots of threads).
After use, the memomry will me unmmapp’ed,
and the process will start again. Many of these
cycles will happen.
As I understand it, malloc’ed memory is not re-used
when free’ed until the process ends (or it the thread?).
So in a scenario like the above, if you did a lot
of malloc/free, you could potentially run oout of memory.
Do I have the malloc/free story straight?
Is this the case for mmap’ed memory as well?
malloc()ed memory is not given back to the OS until the process ends.
But the same process can re- malloc() that same memory.
However, there is some overhead to malloc()ing memory. If the buffer
sized are consistant (or you can assume some arbituary maximum), just
pre-allocate X number of buffers (probibly one for each thread would
be a good idea) and implement your own buffer management. It slould
be much faster than malloc().
In developing a frame grabbing application under QNX 6.2.0,
one architectual choice is to have the FG deliver the
image straight into a piece of memory previously mmapp’ed
and passed to the driver to use.
(One process, lots of threads).
After use, the memomry will me unmmapp’ed,
and the process will start again. Many of these
cycles will happen.
As I understand it, malloc’ed memory is not re-used
when free’ed until the process ends (or it the thread?).
So in a scenario like the above, if you did a lot
of malloc/free, you could potentially run oout of memory.
Do I have the malloc/free story straight?
Is this the case for mmap’ed memory as well?
malloced memory may not be released right away, but it will be released
as the allocator sees fit.
Basically malloc/free is built upon mmaping large chunks of memory, from
which smaller allocations are made. When a chunk it completely freed
it may be munmaped.
On 27 Feb 2003 20:59:41 GMT, Colin Burgess <cburgess@qnx.com> wrote:
acellarius@yahoo.com > wrote:
In developing a frame grabbing application under QNX 6.2.0,
one architectual choice is to have the FG deliver the
image straight into a piece of memory previously mmapp’ed
and passed to the driver to use.
(One process, lots of threads).
After use, the memomry will me unmmapp’ed,
and the process will start again. Many of these
cycles will happen.
As I understand it, malloc’ed memory is not re-used
when free’ed until the process ends (or it the thread?).
So in a scenario like the above, if you did a lot
of malloc/free, you could potentially run oout of memory.
Do I have the malloc/free story straight?
Is this the case for mmap’ed memory as well?
malloced memory may not be released right away, but it will be released
as the allocator sees fit.
Basically malloc/free is built upon mmaping large chunks of memory, from
which smaller allocations are made. When a chunk it completely freed
it may be munmaped.
Thanks for the posts.
So if I understand correctly, many mmap/munmap cycles are potentially
not a good thing, if the idea is for a process to stay around forever.
So one should rather manage a number of buffers onesself to avoid munmap’ing
continuously.
The driver delivers the data via DMA.
What other choices could one look at?
On 28 Feb 2003 14:23:42 GMT, Colin Burgess <cburgess@qnx.com> wrote:
So if I understand correctly, many mmap/munmap cycles are potentially
not a good thing, if the idea is for a process to stay around forever.
So one should rather manage a number of buffers onesself to avoid munmap’ing
continuously.
It’s not so much to do with how long the process stays around, but rather
how often you are doing it.
If the process were to exit, the memory would be reclaimed.
One possibility is for a process to be spawned for every image
captured, process its data, and exit. The frame processing can
take a few seconds, and multiple images may have to be processed.
The application is bursty, with high peaks of activity, followed
by longer time of inactivity. The images could be captured at
somethings like 2/second for a few seconds, but then take 2-3
seconds to process.
The driver delivers the data via DMA.
What other choices could one look at?
I would mmap a pool of buffers. Then you only need to mmap extra buffers
if you exhaust the pool.
On 28 Feb 2003 14:23:42 GMT, Colin Burgess <> cburgess@qnx.com> > wrote:
So if I understand correctly, many mmap/munmap cycles are potentially
not a good thing, if the idea is for a process to stay around forever.
So one should rather manage a number of buffers onesself to avoid munmap’ing
continuously.
It’s not so much to do with how long the process stays around, but rather
how often you are doing it.
If the process were to exit, the memory would be reclaimed.
One possibility is for a process to be spawned for every image
captured, process its data, and exit. The frame processing can
take a few seconds, and multiple images may have to be processed.
The application is bursty, with high peaks of activity, followed
by longer time of inactivity. The images could be captured at
somethings like 2/second for a few seconds, but then take 2-3
seconds to process.
Note that process creation is a relatively expensive process. I wouldn’t
be repeatedly spawning/destroying processes for any high performance system.
The driver delivers the data via DMA.
What other choices could one look at?
I would mmap a pool of buffers. Then you only need to mmap extra buffers
if you exhaust the pool.