ron@Eyring.COM (Ron Holt) (11/20/90)
It has been mentioned to me that Arix provides a alternative read() call that can improve performance for real-time applications. If I recall correctly, the system call looks like this: n = rread(int fd, char **buf, int nbytes) In other words, the OS returns a POINTER to the buffer that the OS (not the user) selected into which the data is put. The idea is that by letting the OS tell the user where it already has the data, a data copy can be avoided. I believe there is also a rfree() call to free this buffer. I have several questions about this interface: Can anyone verify if my information is correct? Can you tell me more about this interface? A summary from the man pages perhaps? Is there a counterpart to this scheme for write()? How much does this help application performance? Does anybody have actual performance figures? What are the drawbacks to using this approach? Thanks. -- Ron Holt ron@Eyring.COM uunet!lanai!ron Eyring Inc. +1 801-375-2434 x434
dale@convex.com (Dale Lancaster) (11/21/90)
In <1990Nov19.161402.7646@Eyring.COM> ron@Eyring.COM (Ron Holt) writes: >In other words, the OS returns a POINTER to the buffer that the OS >(not the user) selected into which the data is put. The idea is that >by letting the OS tell the user where it already has the data, a data >copy can be avoided. I believe there is also a rfree() call to free >this buffer. > How much does this help application performance? Does > anybody have actual performance figures? Unless you go through a buffer cache, most device drivers I have seen or written for Unix uses the process' own buffer to transfer data directly to/from without the intermediate copying to an internal buffer. So providing a rread() seems redundant or unnecessary since how the data is handled is driver dependent and can generally be transferred from user space to device without copying. > What are the drawbacks to using this approach? Its not portable and is redundant to what should be able to be done anyway with a normal read or write. Maybe the vendor had a special need and decided to get around it with a new system call. Using an ioctl is the preferred method for non read/write IO activity system calls. :-) dale
ron@Eyring.COM (Ron Holt) (11/30/90)
In article <dale.659144930@convex.convex.com> dale@convex.com (Dale Lancaster) writes: >Unless you go through a buffer cache, most device drivers I have seen >or written for Unix uses the process' own buffer to transfer data >directly to/from without the intermediate copying to an internal buffer. >So providing a rread() seems redundant or unnecessary since how >the data is handled is driver dependent and can generally be transferred >from user space to device without copying. I was not implying that a rread() call would be used to read directly from a device driver. In particular, I'm interested in knowing how such a call might help reading from a socket, for example, that has several layers of networking protcols below it. Down at the lowest levels of the protocol stack, the network interface driver needs to have some place to put the data it has just received from the network. A typical implementation will allocate a system buffer (e.g. a BSD 'mbuf'), copy the data into it and pass this buffer up to the upper layers of the kernel where it gets copied again into the buffer that was specified by the user's read() call. A rread() call (if I understand it correctly) would skip the last copy and return to the user the address of the mbuf. Avoiding data copies is very important to the performance of network protocols. The hard part is how to make the low level drivers copy data directly into a user's buffer before the protocol processing has taken place that tells the kernel to what user the packet is directed. Nobody has replied yet that has experience with the Arix rread() call. I did get one reply that suggested looking at the POSIS aread() call if anyone is interested: Someone else writes: > I would say that a better performance enhancement is the POSIX 1003.4 > Asynchronous I/O features. Rather than let the OS return the pointer to > the data the application "posts a read" via aread() that contains a > completion function that is called when the I/O is completed. This way > the OS can keep the users buffer and do I/O directly into it. It works the > same way with awrite(). This avoids the rfree() call. Thanks for the replies. -- Ron Holt ron@Eyring.COM uunet!lanai!ron Eyring Inc. +1 801-375-2434 x434