Linux-kernel mailing list archive 1999-22,: Re: zero-copy TCP fileserving

# Re: zero-copy TCP fileserving

Linus Torvalds (torvalds@transmeta.com)
4 Jun 1999 07:45:51 GMT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Linus Torvalds: "Re: zero-copy TCP fileserving"
- Previous message: Andy Sloane: "Re: VAIOs and Linux (was Re: 2.3 wish: integrate pcmcia into mainstream kernel"
- In reply to: zero-copy TCP fileserving: "zero-copy TCP fileserving"

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/

- Next message: Linus Torvalds: "Re: zero-copy TCP fileserving"
- Previous message: Andy Sloane: "Re: VAIOs and Linux (was Re: 2.3 wish: integrate pcmcia into mainstream kernel"
- In reply to: zero-copy TCP fileserving: "zero-copy TCP fileserving"