 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||
Example
editAny one can give a example about zeor-copy in Linux/BSD system ? —Preceding unsigned comment added by Nexthop (talk • contribs)
- Some of the Linux network drivers use zero-copy, as described in the article. -- RevRagnarok Talk Contrib Reverts 18:29, 3 July 2006 (UTC)
Zero-copy drawbacks are not shown here at all. Perhaps there should be an extra paragraph to explain to what extent it can be a solution to reduce PIO cost, mentionning that zero-copy sometimes brings memory registration problems for user-space buffers, as this is the case with high speed networks ... (Gonnet 23:35, 29 July 2007 (UTC)User:Gonnet)
"For example, a 1 GHz processor can handle a 1 Gbit/s network link with conventional data copying, but that same processor will be overwhelmed by a 10 Gbit/s link" This strikes me as patently false - GHz and Gbit/s are not comparable. For a start, a 32-bit processor can process up to 32-bits in one operation; but likewise it will take more than one clock cycle to process that information. I would contend that this sentence be removed. --Dotwaffle (talk) 10:25, 12 October 2010 (UTC)
The Windows <a href="http://msdn.microsoft.com/en-us/library/ms740565(v=VS.85).aspx">TransmitFile</a> call allows a maximum of two concurrent TransmitFile calls on client versions of Windows. This is probably worth mentioning on the main page. — Preceding unsigned comment added by 66.192.178.162 (talk) 19:46, 9 September 2013 (UTC)
Good article structure
editThe current version (from 19 June 2014) of the article has a good structure:
- Principle
- Hardware implementations
- Programmatic access. I suggest this structure to be maintained and the sections to be extended. User:ScotXWt@lk 11:14, 19 June 2014 (UTC)
— Preceding unsigned comment added by Olly The Happy (talk • contribs) 09:36, 17 July 2014 (UTC)
Direct I/O?
editCould we say Linux Direct I/O is equivalent to zero-copy? [1] I think it is, in the sense that it avoid any copy in the kernel. I propose to add at least the reference.
--Olly The Happy (talk) 09:43, 17 July 2014 (UTC)
I think it is valuable to add that zero-copy is also implemented in VMware´s vmxnet virtual NIC driver. — Preceding unsigned comment added by 177.169.252.131 (talk) 22:56, 1 December 2012 (UTC)
References
- ^ Linux Device Drivers, Jonathan Corbet, Alessandro Rubini and Greg Kroah-Hartman, 3rd edition, 0'Reilly 2005, chapter 15, section Performing Direct I/0, pp 435-437
locate-mode
editI found this article when wondering why there is no discussion of locate-mode I/O anywhere. The important idea of locate-mode is to reduce copying, even in a higher-level language. In PL/I, you can do locate-mode I/O, such that a READ, instead of copying data into your buffer gives you a pointer to the actual system buffer. To write, you request a pointer to the output buffer, work on the data there, then ask for it to be written out. This bypasses any copy between the user buffer and the system I/O buffers. I notice the OS/360 example, but as far as I know, the OS360 nucleus (what might now be called kernel) never copies data. Gah4 (talk) 17:51, 1 May 2020 (UTC)
Added more reference sources
editAs per request of "This article relies largely or entirely on a single source ..." I have added a few more reference links to better illustrate the concept of zero copy used in operating systems. Ade56facc 13:44, 14 October 2021 (UTC)
trailers
editWhile zero copy is nice, it is not always possible. One should, though, still have to goal to minimize copies. I am reminded of RFC893, trailer encapsulation for TCP/IP data, which was meant to minimize copies. (Though it never caught on and is now depricated.) The usual IP implementation has various headers, some variable length, that are added as data goes through steps on its way to being sent, and removed after being received. That can be done by copying to the appropriate place in a buffer and then writing the header bytes. Trailer encapsulation puts the added data at the end, avoiding such copies. Even more, it was designed such that one could keep buffers on a page boundary (512 bytes on VAX), though that might not always be needed. In any case, there is a lot of data movement in some systems, and minimizing it makes some sense. Gah4 (talk) 15:06, 14 October 2021 (UTC)