The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Andrew Warkentin <andreww591@gmail.com>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] CMU Mach sources?
Date: Sun, 23 Jun 2019 02:52:30 -0600	[thread overview]
Message-ID: <CAD-qYGrc=sexXKOKkqvdmHfrutt4ET7C_R8h+WoCAb-mhruncg@mail.gmail.com> (raw)
In-Reply-To: <20190623051500.GL30743@mcvoy.com>

On 6/22/19, Larry McVoy <lm@mcvoy.com> wrote:
> I've read the Mach source.  Not a fan.  If you look around you can find
> SunOS 4.x sources, not legal but it is out there.
>
> If you read the SunOS vm code enough, it will come into focus for you.
> The code matches what you think a VM system should be.
>
> If you read the Mach code, nope, it's a tangled mess, there is no
> clear picture there.
>
> I read the papers and wanted to believe it was good, it is not.
>
I've never actually read Mach's sources, but it doesn't surprise me
that Mach's implementation is every bit as much of a train wreck as
its design. Mach and the other kernels influenced by it basically
destroyed the reputation of microkernels, even though there were
microkernels that performed comparably to or better than monolithic
kernels that actually predated Mach et al. There was one paper from
1992 [1] in which an early version of QNX 4 significantly outperformed
System V in just about every category benchmarked (one of these days I
should try to benchmark a newer version of QNX against Linux and see
if the results still hold up). I wonder, had QNX or something like it
had been the "next big thing" in the late 80s and early 90s rather
than Mach, if microkernels wouldn't have become the dominant OS
architecture, or at least a credible alternative.

I also wonder if a modern highly optimized microkernel OS could still
outperform monolithic kernels. Current open-source microkernel OSes
seem to focus on academic purism rather than real-world performance
(one of the biggest issues is that they tend to split subsystems up
vertically with little benefit to security or stability, and probably
adding significant overhead to system calls; e.g. on noux under
Genode, a simple read() of a disk file, which is a single kernel call
on a monolithic kernel and usually two context switches on QNX, takes
at least 8 context switches - client->VFS->disk FS->partition
driver->disk driver and back again).

I may find out once I get UX/RT [2] (the QNX/Plan 9-like seL4-based OS
I'm writing) working, since it will focus on real-world performance
over academic purism (I'm an architectural purist in many ways, but I
think purism must further performance and usability, not hinder them),
although I don't necessarily expect early versions to have the best
performance because the implementation will probably be suboptimal in
places. I'm still a ways from getting it working though.

[1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf
[2] https://gitlab.com/uxrt

  reply	other threads:[~2019-06-23  8:52 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-23  4:38 Chris Hanson
2019-06-23  5:15 ` Larry McVoy
2019-06-23  8:52   ` Andrew Warkentin [this message]
2019-06-23 13:39   ` Jon Forrest
2019-06-23 13:59     ` arnold
2019-06-23 14:03     ` Jason Stevens
2019-06-23  8:04 ` Jason Stevens
2019-06-23 14:54   ` Henry Bent
2019-06-23 21:52     ` Clem Cole
2019-06-25  0:06       ` Larry McVoy
2019-06-25  0:31         ` Theodore Ts'o
2019-06-25  0:45           ` Larry McVoy
2019-06-25  0:55             ` Kurt H Maier
2019-06-25  4:18               ` Larry McVoy
2019-06-26 23:19                 ` [TUHS] Craft vs Research (Re: " Bakul Shah
2019-06-27  0:16                   ` tuhs
2019-06-27 17:06                     ` Clem Cole
2019-06-25  1:00             ` [TUHS] " Richard Salz
2019-06-25  8:00               ` Kevin Bowling
2019-06-25 12:11                 ` Arthur Krewat
2019-06-25 12:17                   ` Arthur Krewat
2019-06-26  2:45               ` Kurt H Maier
2019-06-26  2:56                 ` Larry McVoy
2019-06-26 15:11                   ` Theodore Ts'o
2019-06-26 17:44                     ` Larry McVoy
2019-06-26 18:01                       ` arnold
2019-06-26 18:18                         ` Warner Losh
2019-06-26 19:22                       ` Chris Hanson
2019-06-26 19:32                         ` Ben Greenfield via TUHS
2019-06-26 20:21                           ` Larry McVoy
2019-06-27  0:22                             ` Chris Hanson
2019-06-27  1:02                               ` Larry McVoy
2019-06-27  1:26                                 ` Chris Hanson
2019-06-27  4:01                             ` Lyndon Nerenberg
2019-06-27 10:34                               ` Ben Greenfield via TUHS
2019-06-27 10:59                                 ` arnold
2019-06-27 11:13                                   ` Ben Greenfield via TUHS
2019-06-27 11:39                                     ` arnold
2019-06-27 14:58                                     ` Warner Losh
2019-06-27 17:25                                       ` Larry McVoy
2019-06-26 19:30                       ` Dennis Boone
2019-06-26 19:25                     ` Adam Thornton
2019-06-23  8:27 ` Kevin Bowling
2019-06-25  3:07 ` Gregg Levine
2019-06-25  8:15   ` Kevin Bowling
2019-06-25 18:18   ` Chris Hanson
2019-06-25 20:23     ` Gregg Levine
2019-06-26  1:04       ` Jason Stevens
2019-06-26  0:53     ` Jason Stevens
2019-06-25  7:49 ` Jason Stevens
2019-06-25  7:59   ` Andreas Grapentin
2019-06-23 22:08 Noel Chiappa
2019-06-23 23:54 ` Theodore Ts'o
2019-06-24 17:04   ` Jason Stevens
2019-07-01 13:20 Jason Stevens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD-qYGrc=sexXKOKkqvdmHfrutt4ET7C_R8h+WoCAb-mhruncg@mail.gmail.com' \
    --to=andreww591@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).