> Actually, network data servers (e.g., NFS, FTP, non-CGI HTTP, ...)
> really do little to no "real computation". [...]
and thats about it. You have just listed _3_ applications which happen to
make good use of zero-copy - but thats it. Yes, file servers are an
important category, but a fileserver is mostly IO-limited anyway ...
> 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 [..]
it 'just' doesnt support CGI scripts? What is your current estimation,
what is the ratio between dynamic and static content amongst say the
top100 web sites on the web? Can we say 0% static pages? [yes, i accept
Dean Gaudet's point that webpages can be split up into dynamic and static
parts, probably that will be the future.]
> 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).
these things are not being ignored, really. It's just a limited subset of
applications - and zero-copy makes a RL difference only in a small part of
those uses. It can make a difference, but due to it's limited use it is
only acceptable in a generic OS if the framework puts no complexity into
other parts of the kernel. _This_ is the main difference. Yes we like
zero-copy, but only if it's a by-product of another, useful concept. (eg.
the newest pagecache in the works will enable us to do receivefile(),
pushfile(), copyfile() and movefile() - basically IO-lite.) I very much
dislike zero-copy-maniac designs which give up just about everything to
get nice bandwith numbers.
> > 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
no, it doesnt have to be balanced. If doing bandwith vs. latency decisions
then latency is _the_ top goal. Yes we want to have bandwith too - if
possible.
> 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...
dont forget that Linux became only possible because 20 years of OS
research was carefully studied, analyzed, discussed and thrown away.
-- mingo
-
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/