Re: a joint letter on low latency and Linux

From: Peter Rival (frival@zk3.dec.com)
Date: Wed Jul 05 2000 - 08:51:29 EST


Steve VanDevender wrote:

> Albert D. Cahalan writes:
> > Digital UNIX (now Tru64, was OSF/1) uses self-modifying code to
> > create a generic kernel that can do, if I remember right:
> >
> > 1. plain
> > 2. real-time
> > 3. SMP
> > 4. real-time SMP
> > 5. lock debugging
>

<snip>

>
> I don't think any sane person would want to maintain whatever
> self-modifying code tricks that Digital UNIX might use to accomplish
> this fabled feat.

Have you actually looked at the code that does the self-modification work?
It has remained (so far) fairly stable for quite a while. The big
difference, which I don't believe most people understand, is that Linux
inlines its locking code whereas Tru64 does not. That makes the code
modification work much more simple. Just take a look at the assembly code of
simple_lock_patch_init() in dbx - it's really quite straightforward.

> And did I mention that the Digital UNIX kernel is a
> massive 8 megabytes _after_ you prune out most of the optional features?

Did you ever notice that it also still has all of its symbols and debugging
info in the same file? The Linux vmlinux.gz/bzImage is stripped and
compressed; a correct comparison would be between a vmlinux (not vmlinux.gz)
image built with -g3, that way all the same information is present in both.

I'm not saying anything is better or worse for Linux or Tru64 - there are
definite advantages to both ways of doing things. I just want to make sure
that if people are going to think about trying to do things the way Tru64
does them they are fully informed. And considering that I'm getting paid to
make comparisons between Tru64 and Linux at a code level, one could hopefully
say that I'm fairly well informed. ;)

 - Pete

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:16 EST