> > You're missing my point just to be rude and obnoxious.
> 
> No, I got your point. The point was that your point is
> meaningless. Saving 20 instructions here and 10 instructions there is
> useless except in the inner loop of DES or an MPEG decoder.

Well, if you save 100 instructions in the schedule routine there; a
couple thousands in the TCP/IP checksuming code there and do not copy
twice packets, we start to get some nice numbers.  Why don't you go
try Linux on a SPARC and then come back and tell us if it feels faster
or not.

> What matters far more is algorithms. I remember when Linux used a
> linear list for the routing table, and NetBSD used a PATRICIA
> tree. No number of instruction bums on the linked list were going to
> come near a PATRICIA tree no matter what you tried.

What is the point here?  As David said, his expertise is best used at
optimizing our SPARC port and doing the dirty job fast and well done.
People like Alan Cox, Stephen Tweedie, Linus, Matthias, Remy Card,
Eric Youngdale, Olaf, Pedro Roque, Erik Schenk, Mike Jaggdis, Ted Tso, HJ
Lu do optimizations on other areas of the Linux operating systems and
fix and enhance those parts.  

Linus just went to redesign the way the information is moved from user
space to kernel space; Olaf is finishing his new NFS client and server
code; Stephen has some new vitamins for our VM system; Eric is coming
up with some enhancements to ELF that will allow Linux userland
applications to use the best from every single different chip; Pedro,
Alan and Erik have been doing ipv6 and have been adding to the Linux
TCP/IP stack the latest research optimizations to the TCP/IP protocol
(copy checksum, and pbuffs, both from Jacobson and first implemented
in BSD are not currently available in any BSD distribution, Linux on
the other hand has them).  

So, lets help David do his best work at doing what he is very good at.

> I didn't say things couldn't be optimized. I said the kernel isn't a
> bottleneck.

Imagine that kind of applications that like to do read (fd, &c, 1)
thousands of times.  I bet Linux can handle those better than other
OS's thanks to its low system call entry/exit times.

> On networking, well, my kernel already totally saturates my ethernet
> without taking significant CPU time. This means there is no point in
> optimizing it further. When I go for 100Mbps ethernet, then it will be
> time.

Well, see, we are actually worried because we want to achieve the
best from the already available 100Mbps networks.  David already is
optimizing our 100 Mbps ethernet SPARC driver (btw, we already are
faster than Solaris on better hardware).

> What is the point of spending serious time on optimization of
> something that only consumes a few percent of your CPU? If you are
> hitting the wall, 5% usually doesn't help you. You mentioned Wall
> Street. 

5% here, 5% there.  Larry has already made a nice and clean
explanation on this matter on this discussion.

Miguel.