> 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/