At 19:38 -0700 10/22/96, Rick Kelly wrote:
>David S. Miller said:
>
>>So true.  Especially as of late my stream of consciousness has been
>>"geese, it has been almost two days since I was able to suck a couple
>>hundred cycles out of a major critical code path, I'm slacking off
>>again."
>
>You'll regret this later when you understand that the primary reason
>for developing an OS is to run lmbench REAL FAST.

An operating system should impose minimum overhead costs on a computer at
all times, and we should strive to push that overhead down further. Does
anyone disagree?

The only thing worrisome in this discussion so far is the suggestion that
the Linux system call method might have some questionable corner cases. The
nasty there is that if there are unhandled (or ungraceful) corner cases,
the probability that they will show up someday approaches one as the
operating system (or the technique, across multiple operating systems) gets
more widely used.

On the flip side, pulling as many instructions out of an execution path as
possible is a discipline I wish more programmers would practice; if they
did, we might actually get the "factor of N" performance increases in real
performance that things like doubling and tripling CPU clock rates imply.
Dr. Dave Clark said it in the context of network performance, years ago:
"optimize for the common case first."

It seems to me that in the modern world, we rely far too much on the fact
that the hardware keeps getting faster (so far), and so we can do more, but
we attempt to do more without regard for the levels of efficiency that used
to be the watchword of systems programmers everywhere even just a few years
ago. As the old adage goes, "the hardware giveth, and the software taketh
away."

If the Linux folks have come up with a better mousetrap, let's use it, and
not worry about where it came from. The proof is in the implementation:
does it work as advertised, or not?

Particularly since lots of folks are using older hardware, it would be a
terrific thing if we can give everyone a few percent more cycles with each
release.

	an old kernel hacker with rusty skills,

	Erik Fair