Our driver needs to allocate/free chunks of physical memory to exchange
data (PCI DMA) with a custom board.
Buffers alloc/free may be performed during other DMA activity (other
channels working on the board), and buffers dimension can reach some
MBytes (4 MB for example).
The qnx_segment_alloc() and qnx_segment_alloc_flags() allocate 0-filled
memory, and I have noticed that the “memset to 0” is performed in the
qnx_segment_free() call (memory is left clear when available for
allocation).
The problem is: qnx_segment_free(4MB buffer) takes more than 16 ms to
execute (PIII 700MHz, 133MHz RAM), and this is fatal for our application
(it must handle several interrupt events each ms).
Is there a good workaround to this?
Is it possible to tell to a lower priority process to unmap and free the
physical buffer for us?
Our driver needs to allocate/free chunks of physical memory to exchange
data (PCI DMA) with a custom board.
Buffers alloc/free may be performed during other DMA activity (other
channels working on the board), and buffers dimension can reach some
MBytes (4 MB for example).
The qnx_segment_alloc() and qnx_segment_alloc_flags() allocate 0-filled
memory, and I have noticed that the “memset to 0” is performed in the
qnx_segment_free() call (memory is left clear when available for
allocation).
The problem is: qnx_segment_free(4MB buffer) takes more than 16 ms to
execute (PIII 700MHz, 133MHz RAM), and this is fatal for our application
(it must handle several interrupt events each ms).
Is there a good workaround to this?
If you’re alloc/free() in large hunks of memory, why free it if you’re going
to need it again? Divide it up into smaller hunks, and keep a freelist
around. This is a common optimization to amortize the cost of the initial
alloc over the life span of the process.
Is it possible to tell to a lower priority process to unmap and free the
physical buffer for us?
That wouldn’t make much of a difference, since Proc eventually does the
work, and not at low priority. Well, actually it might, but for different
reasons - if the process requesting the segment_free() was of low enough
priority, you could infer that if it’s running, nothing else of priority
requires the system and thus might be safe to do the time munching free.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Our driver needs to allocate/free chunks of physical memory to exchange
data (PCI DMA) with a custom board.
Buffers alloc/free may be performed during other DMA activity (other
channels working on the board), and buffers dimension can reach some
MBytes (4 MB for example).
The qnx_segment_alloc() and qnx_segment_alloc_flags() allocate 0-filled
memory, and I have noticed that the “memset to 0” is performed in the
qnx_segment_free() call (memory is left clear when available for
allocation).
The problem is: qnx_segment_free(4MB buffer) takes more than 16 ms to
execute (PIII 700MHz, 133MHz RAM), and this is fatal for our application
(it must handle several interrupt events each ms).
Is there a good workaround to this?
If you’re alloc/free() in large hunks of memory, why free it if you’re going
to need it again? Divide it up into smaller hunks, and keep a freelist
around. This is a common optimization to amortize the cost of the initial
alloc over the life span of the process.
Is it possible to tell to a lower priority process to unmap and free the
physical buffer for us?
That wouldn’t make much of a difference, since Proc eventually does the
work, and not at low priority. Well, actually it might, but for different
reasons - if the process requesting the segment_free() was of low enough
priority, you could infer that if it’s running, nothing else of priority
requires the system and thus might be safe to do the time munching free.
In our QNX box Proc32 is runnig at prio 27, our driver has prio 29. This
avoid the priority problem you have described above.
In our QNX box Proc32 is runnig at prio 27, our driver has prio 29. This
avoid the priority problem you have described above.
Be aware that running a process higher than Proc’s priority can have adverse
effects. Services that Proc provides now occur at the mercy of your
process - I imagine that you’re doing as little work as possible in this
“high” priority process.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Our driver needs to allocate/free chunks of physical memory to exchange
data (PCI DMA) with a custom board.
Buffers alloc/free may be performed during other DMA activity (other
channels working on the board), and buffers dimension can reach some
MBytes (4 MB for example).
The qnx_segment_alloc() and qnx_segment_alloc_flags() allocate 0-filled
memory, and I have noticed that the “memset to 0” is performed in the
qnx_segment_free() call (memory is left clear when available for
allocation).
The problem is: qnx_segment_free(4MB buffer) takes more than 16 ms to
execute (PIII 700MHz, 133MHz RAM), and this is fatal for our application
(it must handle several interrupt events each ms).
Is there a good workaround to this?
If you’re alloc/free() in large hunks of memory, why free it if you’re
going
to need it again? Divide it up into smaller hunks, and keep a freelist
around. This is a common optimization to amortize the cost of the initial
alloc over the life span of the process.
Is it possible to tell to a lower priority process to unmap and free the
physical buffer for us?
That wouldn’t make much of a difference, since Proc eventually does the
work, and not at low priority. Well, actually it might, but for different
reasons - if the process requesting the segment_free() was of low enough
priority, you could infer that if it’s running, nothing else of priority
requires the system and thus might be safe to do the time munching free.
A couple of years ago there was a similar discussion about this issue. The
rationnal for clearing the memory was security, you don’t want to have a non
root program live at the location where a root program once ran and be able
to gather sensitive information just by scanning the memory. That seems
like a very valid argument. It was suggested Proc32 could have an option to
disable the clearing of the memory region upon being freed. At the time it
sounded like a good compromise. Don’t know why it never was implemented.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
A couple of years ago there was a similar discussion about this issue. The
rationnal for clearing the memory was security, you don’t want to have a
non
root program live at the location where a root program once ran and be
able
to gather sensitive information just by scanning the memory. That seems
like a very valid argument. It was suggested Proc32 could have an option
to
disable the clearing of the memory region upon being freed. At the time
it
sounded like a good compromise. Don’t know why it never was implemented.
Feature request revival - I’ll take a peek and see
Any ideas on when the discussion was (I’m assuming newsgroups here, not cube
corridor chatter)?
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
A couple of years ago there was a similar discussion about this issue.
The
rationnal for clearing the memory was security, you don’t want to have a
non
root program live at the location where a root program once ran and be
able
to gather sensitive information just by scanning the memory. That seems
like a very valid argument. It was suggested Proc32 could have an
option
to
disable the clearing of the memory region upon being freed. At the time
it
sounded like a good compromise. Don’t know why it never was
implemented.
Feature request revival - I’ll take a peek and see >
Any ideas on when the discussion was (I’m assuming newsgroups here, not
cube
corridor chatter)?
Try quics I’ll see if I can find it tonite (not in office at the
moment)
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
I’ll see if I can find it tonite (not in office at the