[ Sorry to jump into this so late; My e-mail address got popped off
  tech-kern somehow... I've read the archives to catch up :-) ]

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

 > 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.

I'd definitely agree with Perry, here.  Concentrate on optimizations
which give you a big gain, at first.  As Perry noted, often these
optimizations come in the form of different data structures and/or
algorithms.

If you're looking to shave a usec or 3 off of a system call, consider
all of the other things that might be occurring in a Real Life
system call.  The value of shaving a usec or 3 off the call overhead
is like saying "My sports car is too heavy; I think I'll drill holes
in the clutch pedal." (yes, I know Mazda did this with the new RX-7s).

When you micro-optimize, you have to see really long uptimes in order
to see the benefit from this... When you've saves 3 usec off system
call overhead, how much of a measureable performance difference have
you _really_ seen in real-world applications?  In any case, in my
experience, I've never seen a Linux system stay up long enough to
get a real benefit from micro-optimization :-)  *duck*

[ David sez ]
 > > I end with a simple question: "If Charles Schwab on system B could get
 > > transactions more quickly then any other broker, much more quickly
 > > than they do now with system A, do you think they would switch to B?"

I would say that Charles Schwab ought to have some real, concrete
evidence that there's a real performance benefit from switching
systems.  Moving your bread-and-butter around is a risky proposition,
one which a conservative individual would likely baulk at if the
gain was (at best) negligible.

It occurs to me that David is arguing by assertion... I want to see
numbers (other than lmbench, which is a micro-benchmark, and thus useless
for measuring real-world performance gains, as far as I'm concerned)
that prove that shaving 3 usec off of system call overhead really makes
a difference to applications (which is what computers are for, right?).

 > I've said repeatedly, the kernel isn't a bottleneck for most
 > applications. If you are building a tickerplant, the quality of your
 > VM system and the amount of memory you have is the key. If you are

Just a minor nit, Perry... the VM system is in the kernel :-)

But, to address Perry's point, optimizing your VM system isn't about
micro-optimizations.  You're typically looking for more efficient
ways to store/find information.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939