Subject: Re: Linux: the next step

From: [email-masked] (Larry McVoy)
Date: Fri, 02 Aug 1996 18:11:31 -0700

: Dream on!  Here in ISD (Indigo2 land), we're working flat out just to
: get IRIX to run on any new platforms at first shipment, with all
: the neat features supported.  I think you'll find the same
: is true of all the other product divisions.

It's hard work.  I know people are working hard to keep IRIX going.  And 
there is a lot in IRIX that isn't in Linux.

However, there's a lot in IRIX that shouldn't be in IRIX, let alone Linux.
One of the cool things that David has done this summer was to keep the
generic code free of #ifdef *_WAR stuff that is littered throughout the
IRIX kernel.

: We are neither a hardware company nor a software company.
: We are a *systems* company.  

I agree.  But answer these questions:

	. would anyone buy our hardware if we didn't put the software on it?

	. would anyone buy our software on some other hardware?

I think that gives you an answer to what kind of comapny we really are.

: As for Linux,
: when will it support true symmetric multiprocessing with fine-grained
: semaphore and mutex locking, and a fully preemptible kernel?

The fine grained locking is a lose.  It costs us way too much and what I
am seeing is a trend backwards towards coarser grained locking.  If this
wasn't true, why did we build lego?  Why are we building Nexus?

Linux already has a RT kernel.  I just reviewed a fantastic Usenix paper
that added RT to Linux - fully preemptable, hard real time to < 100 usecs,
and less than 3K lines of code change.  Their test case was a 100Khz clock
pulse on a parallel port; they got it every time, with less than 15usecs
skew, while the system was tar-ing one file system to another, running 
netscape, and generally doing same old Unix stuff just like normal.  It's
really impressive and very uninvasive.

: At the San Diego Usenix earlier this year, Linus Torvalds
: thought that the probable answer was "not anytime soon".
: (By the way, in order to do this correctly, every device driver would
: have to be rewritten.)  

Almost none of the drivers need a rewrite for the RT stuff.  That work was
a good example of what I call "orthogonal thinking" or using a completely
different approach to solve the problem.

: Linux would need this *at a minimum* before
: there is any hope that it would supplant IRIX on the current
: generation of hardware, let alone any future new platforms.

Linux isn't going to replace IRIX any time soon.  However, Linux is
going to show off MTI's chips and SGI's hardware in a somewhat more
positive light.  If all that happens is that people get psyched about
the "hidden" performance in SGI hardware and get IRIX to show off that
performance, then the paltry amount we've spent on Linux will be worth it.

Finally, think about this:  how many times have you had a "great idea"
for better IRIX performance, gone off an prototyped it, only to find
that it makes no difference?  Linux lets you test out those ideas and
see the real performance difference, unadulterated by any surrounding
bloat.  That's cool.  We want that.

---

From: [email-masked] (Larry McVoy)
Date: Mon, 12 Aug 1996 14:09:39 -0700

: However, I agree that more locking is not the answer.  Eliminating as much
: shared, global data as possible is the answer.  Nexus doesn't really do
: anything towards that end that I can see.

Yeah.

: >Linux already has a RT kernel.  I just reviewed a fantastic Usenix paper
: >that added RT to Linux - fully preemptable, hard real time to < 100 usecs,
: >and less than 3K lines of code change.  Their test case was a 100Khz clock
: >pulse on a parallel port; they got it every time, with less than 15usecs
: >skew, while the system was tar-ing one file system to another, running 
: >netscape, and generally doing same old Unix stuff just like normal.  It's
: >really impressive and very uninvasive.
: 
: I'd like to see that when it comes out.

You'll have to borrow my copy, Usenix rejected it.  Fuckheads.

: >Finally, think about this:  how many times have you had a "great idea"
: >for better IRIX performance, gone off an prototyped it, only to find
: >that it makes no difference?  Linux lets you test out those ideas and
: >see the real performance difference, unadulterated by any surrounding
: >bloat.  That's cool.  We want that.
: 
: If it makes no difference, what difference does it make what platform you try
: it on?  If it does make a difference, you would be able to measure it despite
: the underlying bloat, and again the underlying platform makes no difference.

Suppose you are trying to reach some performance point, X.  Whatever that
is.  You do some work that would, in theory, get you closer to point X.
It doesn't, you can't see the difference.  Just for the sake of argument,
suppose that that work was indeed correctly focussed on something that
needed to get fixed in order to get to point X.  But the effects of that
work were overshadowed by all of the surrounding bloat.  That doesn't mean
that the work was useless or wrong, it means that the bloat dominates.  If
the bloat wasn't there, you would need to do the work to get to X.

A more concrete example: IRIX syscall entry is something like 15-30 usecs,
if I remember correctly.  On Linux, it's about .5 - 5 usecs.  In the
Linux world, optimizations that made a 100% difference would be lost in
the bloat in IRIX.  Does that mean that those optimizations are pointless?

Not to me, it doesn't.  I want a kernel that is fast enough that dropping
into to diddle something and then popping back out is about a procedure
call, no more.  IRIX is miles from that, Linux is approaching it.