Subject: Re: But why?
To: None <email@example.com>
From: David S. Miller <firstname.lastname@example.org>
Date: 10/23/1996 18:44:22
Date: Wed, 23 Oct 1996 18:06:38 -0400
From: "Perry E. Metzger" <email@example.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
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
(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
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