Messages in this thread |  | | | From | (Linus Torvalds) | | Subject | Re: zero-copy TCP fileserving | | Date | 4 Jun 1999 07:45:51 GMT |
| |
In article <UrJhNjG00UwB0ZqZI0@andrew.cmu.edu>, Charles K Hardin <chardin+@andrew.cmu.edu> wrote: > >but isn't the real question - should the copy even take case? i have no >doubt that if a copy occurs, some cheap computation (ie. a cksum can >easily be hidden in the data transfer through the CPU). > >but, why should the copy even occur? there is easily enough research >lingering around these days to show the zero copying is good (Unet for >instance as well as ExoKernel) these were direct access to user space >without copies, but the same philosophy can hold for kernel space.
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..
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.
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.
[ Side tracking from another comment in this thread ]
It's also rather dangerous to look at "scalability" as being the all-important goal to reach for. In many cases scalability does not equal performance. For example, not only is a single gigabit card a much more realistic schenario than having found 100Mbit cards and "scaling" from one to four, but it's actually going to perform better. Scaling is only good if it was fast to begin with ;)
Oh. And ask your MIS department whether they want to try to load- balance four 100Mbit networks by hand, or whether they want to add a gigabit switch somewhere? There are those kind sof issues too..
Linus
- 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/
|  |