Messages in this thread | | | From | Greg Ganger <> | Subject | Re: zero-copy TCP fileserving | Date | Fri, 4 Jun 1999 16:25:32 -0400 (EDT) |
| |
While I applaud Linus for sticking to his philosophical guns, I hope that few people are compelled to ignore 20 years of networking and OS research (and practice) based on his misinformed commentary.
> Zero copy looks good on benchmarks. > > It very seldom wins in real life. You tend to actually want to _do_ > something with the data in most cases, and if the memcpy is even close > to be your limiting factor, that real computation is going to never have > a chance in hell..
Actually, network data servers (e.g., NFS, FTP, non-CGI HTTP, ...) really do little to no "real computation". Further, computation rates continue to grow faster than memcpy rates (particularly, when dealing with I/O devices). As a result, those in industry who build these kinds of products do, in fact, understand the importance of copy elimination, and they spend significant energy to achieve it.
> Zero-copy is mainly useful for routing or for truly pure packet serving. > The ExoKernel numbers, for example, aren't really from a web-server even > though that's what they claim. What they really did was a "ethernet > packet server", feeding canned responses to canned input. It has some > resemblance to web-serving, but not all that much.
This paragraph is complete hogwash. First, Linus clearly does not know what he is talking about with respect to the exokernel's Cheetah web server -- although it did not support CGI scripts (much like NetApp's servers don't), it did in fact do HTTP/1.0 for real. Far more importantly, though, web service can in fact benefit significantly from zero-copy techniques. If you choose to ignore the lessons taught by the exokernel work, perhaps you will be more compelled by the more recent Rice work (IO-lite, which won Best Paper at the recent OSDI'99 conference).
Further, other domains (e.g., IPC, high-speed I/O, cluster computing) benefit significantly from zero-copy cross-domain transfers. There are any number of research projects (e.g., U-net, Fbufs) and industry efforts (e.g., VIA, SiliconTCP) that clearly demonstrate the importance of copy avoidance.
> Also, many of the zero-copy schemes depend on doing mmu tricks, which > often suck for latency even on a single CPU, and are _truly_ horrible in > SMP environments. They get good throughput numbers, but latency numbers > are usually not quoted (or latency was bad enough to start with that it > doesn't much show up as a red flag - quite common). > > There are good arguments for avoiding copying unnecessarily. However, > often trying to drive that logic to it's extreme is only going to make > other issues so much worse that it really isn't worth it in any normal > load.
No arguments here; it is always important to balance performance with issues of complexity and other systemic properties. However, such platitudes hardly provide compelling evidence for ignoring 20 years of networking/OS research and architecting unnecessary copies into the core of an OS that wants to be taken seriously...
Greg Ganger Carnegie Mellon University
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |