Date: Wed, 23 Oct 1996 18:06:38 -0400
   From: "Perry E. Metzger" <perry@piermont.com>

   > If you can find 10 or 20 places where you can do something
   > similar, what does this work out to?

   On my machine, a savings of 0.4%. Still a bit of a yawn, I'd say.

You're missing my point just to be rude and obnoxious.

   I frequently implement optimizations, but they tend to be better
   algorithms. These usually get you BIG improvements -- things like
   multiples in performance, not tiny increments.

Therefore my micro-optimization to memcpy/csum_partial_copy which gave
me 4 or 5 MB/s faster bandwidth over pipes and sockets is a SMALL
improvement?

People like Alan Cox and Linus do this end of the work (your so called
"BIG improvements"), sometimes I play in this realm as well but mostly
I concentrate on architecture specific hacks which is my expertise at
least as of now.

   I've said repeatedly, the kernel isn't a bottleneck for most
   applications.

(I'm quoting Jacobson here, when he heard someone at a conference say
that TCP could never be made to go fast) "Bullshit!"

The cycles and the memory used by the kernel are "gone forever", no
application can ever use those cycles you have lost in supervisor
mode.  Every program on the system reaps the benefits of a faster OS,
why do you think QNX is so popular for the jobs it was designed to
have run under it, because it eats such a low number of cycles in
supervisor mode.

   99% of the problem is in userland.

Therefore, let's make it even worse on userland by having a kernel
that eats more resources than it should.  Indeed, logical.

   In general, the machines are already more than fast enough for the
   job, and the problem people face is application software. Those
   machines that aren't fast enough need more CPU for the userland
   stuff, not for the kernel.

"We have faster boxes, we can afford to let the kernel go a bit slow
 because the hardware is faster now."

I am reminded repeatedly every single day by people like you why we
are indeed amidst a software crisis.

David S. Miller
davem@caip.rutgers.edu