for performance of memmgr.map_xfer functions some QNX Gurus are needed,
but why don't you just do direct IO from your client site using devctl()?
here you're allocating the phys blocks on client site and pass them to your driver.
If needed you could setup a client lib that could be used if you don't want users to handle direct IO on their own.
/hp

>-----Ursprüngliche Nachricht-----
>Von: Mark Pearson [mailto:community-noreply@qnx.com] 
>Gesendet: Donnerstag, 14. Mai 2009 15:09
>An: ostech-core_os
>Betreff: optimizing read/write call performance / contiguous 
>RAM allocation
>
>Hi,
>
>I'm writing a device driver for a fast flash memory device 
>(>90 Mega-Byte/sec). My driver uses DMA to do read and write 
>accesses to the flash memory device (i.e. it is memory mapped).
>
>Using the read and write primitives which I've written, I can 
>read and write at a level of 90 Mega-Bytes per second.
>
>I simply pass my read and write functions a buffer and once 
>the DMA generates an interrupt (saying transfer complete), my 
>functions return. 
>
>The user will access my device driver via POSIX like open, 
>read and write. But I'm finding that using the QNX read and 
>write routines is killing my performance.
>
>I'm down to 25 Mega-Byte/sec read and 16 Mega-Byte/sec write.
>
>I've written io_read and io_write functions, which are called 
>when the user issues a read or write. 
>
>In io_read I need to allocate a physically contiguous buffer 
>for the DMA transfer. I get the physical address of the buffer 
>via mem_offset and then call my device driver to perform the 
>DMA operation.
>Upon completion, I return the buffer to the caller via:
>
>MsgReply(rcvid, size, pContigBuffer, size)
>
>This then take >0.3 Seconds to copy the data from the 
>contiguous buffer which I created to the virtual address space 
>of the buffer which the user passed to me.
>
>This is where my performance is going.
>
>Its a similar situation for write, but the performance hit is 
>bigger, as I have to copy the buffer which I receive via 
>io_write to a physical contiguous buffer which I need for DMA.
>
>The user code will not be written by me and will be within a 
>separate process, so I can't access the physical address of 
>the buffers directly and I won't know if the buffers are 
>physically contiguous - is there maybe a way to force the 
>memory manager to only ever allocate physically contiguous RAM?
>
>And is there also a way of preventing QNX from doing buffer 
>copying in the read/write routines, if the buffers are already 
>physically contiguous?
>
>Any other ideas?
>
>Cheers, Mark.
>
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post29423
>
> 
 
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad | 
Local Court Mannheim: Register No. 361395

 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat 
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly...

A couple of things...

Are you allocating buffers for every read?  Calling mmap() and mem_offset() are, relatively speaking, expensive
calls - they are both msgpasses to procnto.

You should probably cache your buffers, along with their physical addresses.

You don't mention which release you're running on.

I would strongly suggest taking a kernel trace to isolate unknown factors.

Regards,

Colin

Mark Pearson wrote:
> Hi,
> 
> I'm writing a device driver for a fast flash memory device (>90 Mega-Byte/sec). My driver uses DMA to do read and 
write accesses to the flash memory device (i.e. it is memory mapped).
> 
> Using the read and write primitives which I've written, I can read and write at a level of 90 Mega-Bytes per second.
> 
> I simply pass my read and write functions a buffer and once the DMA generates an interrupt (saying transfer complete),
 my functions return. 
> 
> The user will access my device driver via POSIX like open, read and write. But I'm finding that using the QNX read and
 write routines is killing my performance.
> 
> I'm down to 25 Mega-Byte/sec read and 16 Mega-Byte/sec write.
> 
> I've written io_read and io_write functions, which are called when the user issues a read or write. 
> 
> In io_read I need to allocate a physically contiguous buffer for the DMA transfer. I get the physical address of the 
buffer via mem_offset and then call my device driver to perform the DMA operation.
> Upon completion, I return the buffer to the caller via:
> 
> MsgReply(rcvid, size, pContigBuffer, size)
> 
> This then take >0.3 Seconds to copy the data from the contiguous buffer which I created to the virtual address space 
of the buffer which the user passed to me.
> 
> This is where my performance is going.
> 
> Its a similar situation for write, but the performance hit is bigger, as
> I have to copy the buffer which I receive via io_write to a physical contiguous buffer which I need for DMA.
> 
> The user code will not be written by me and will be within a separate process, so I can't access the physical address 
of the buffers directly and I won't know if the buffers are physically contiguous - is there maybe a way to force the 
memory manager to only ever allocate physically contiguous RAM?
> 
> And is there also a way of preventing QNX from doing buffer copying in the read/write routines, if the buffers are 
already physically contiguous?
> 
> Any other ideas?
> 
> Cheers, Mark.
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post29423
> 

-- 
cburgess@qnx.com