TeamForge : Post

Forum Topic - Forwarding large amounts of data:

View: as

Oleh Derevenko(deleted)

12/17/2009 12:28 PM

post44043

Hi,

In QNX 6.3.0SP3 I would like to implement forwarding of large data block read from socket into a write() call over QNet 
to another node (the transfer MUST be performed with a single write). To avoid allocating large memory block on the 
forwarder node I would be eager to implement "read on demand" schema.
For example, having input data amount of NxM bytes, consider setting up I/O vector with with M pointers to a 
inaccessible memory blocks of N bytes each and calling writev(). Then, when kernel attempts to read from memory and 
segmentation fault occurs, the program catches the SIGSEGV remaps the memory to allow access, reads the block from 
socket and exits the signal handler to retry the operation.
Could that be theoretically possible in QNX architecture?

Will Miles

12/17/2009 9:01 PM

post44090

Re: Forwarding large amounts of data

Hi Oleh,

It definitely cannot be done with QNX 6.3.0.  The memory manager used in the older kernel does not support memory pages 
that are not backed by physical or device RAM.

With QNX 6.3.2 or newer, it might be technically possible; the back end used to mmap files might do the trick.   You 
could look in to writing a resource manager that supports mmap, then have a second process mmap MxN blocks from it.  
Then, when that memory is operated on, the kernel will automagically call out to your resource manager to retrieve the 
data.

Of course, whether all this effort actually saves you much remains to be seen - it's entirely possible that what will 
happen is the kernel simply attempting to touch all of the memory before releasing anything to io-net.  Plus you've got 
the additional overhead of maintaining a resource manager and all its associated mechanics and the like; you may not end
 up saving much memory at all.

-Will

Oleh Derevenko(deleted)

12/18/2009 3:31 AM

post44102

Re: Forwarding large amounts of data

> It definitely cannot be done with QNX 6.3.0.  The memory manager used in the 
> older kernel does not support memory pages that are not backed by physical or 
> device RAM.

Well, fine. But what happes when a custom handler for SIGSEGV returns? Does processor retry faulting instruction?
In case of positive answer it could be possible to allocate two pages of physical memory, protect them with PROT_NONE, 
and set iov elements to point to those two pages alternating between them. When a segmentation fault occurs program each
 time unprotects one page and protects another to catch request for next data block.
The only prerequisites would be processor retrying the faulted instruction and handler code knowing the faulted memory 
address.

Return