bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"Microkernels rule!" and the Hurd


From: Neal H. Walfield
Subject: "Microkernels rule!" and the Hurd
Date: Wed, 13 Aug 2008 10:04:29 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

Gernot Heiser recently wrote an article, "Microkernels rule!" for
Embedded.com about microkernels' bad reputation.  I fully agree with
the message of his article: operating systems based on microkernel
technology don't necessarily have to be slow and can be made more
robust than their monolithic counterparts.  However, Gernot mentions
the Hurd and incorrectly describes its position in history:

  Mach, an OS that was widely used as the basis of systems, ran into
  serious performance problems...  There were spectacular failures,
  none more so than IBM's Workplace OS, which cost the company a cool
  two gigabucks...

  Needless to say, the experience with Mach and others created a bit
  of an image problem for microkernels (which didn't stop the GNU Hurd
  from repeating the mistakes of the past).  However, back in 1993,
  Jochen Liedtke demonstrated that these performance problems weren't
  inherent in the microkernel concept.

The Hurd did not repeat the errors of past.  Work on the Hurd started
in 1990.  In GNU's Bulletin January, 1994 [1], you'll find an article
detailing the Hurd's architecture.  Workplace OS was conceived in
1991; it was deemed a failure around 1995.  Jochen's article
"Improving IPC by Kernel Design" was published in December 1993.

Regarding, Workplace OS, its main goals were: machine independence,
multiple personalities, and concurrent operation of personalities [3].
The last two goals, as far as I am aware, were never a priority in the
development of the Hurd.  Further, Workplace OS had already adopted
many second generation microkernel features, for instance, L3's
synchronous IPC.  In the major "Observations and Lessons" section of
[3], this is not even mentioned; management, coordination, and focus
are cited as the major problems.

Finally, the architectural problems that we have identified with Mach
[4] are not related to IPC.  The most important are the lack of
resource accounting, and the bad resource management (paging
decisions).  Regarding the implementation that we use, the major
problems are unoptimized code (e.g., when evicting a bunch of pages,
Mach always sends them one at a time to the manager), and the decades
old code base which was designed for machines with tens of megabytes
of RAM.

Neal


[0] http://www.embedded.com/columns/guest/208800243

[1] http://www.gnu.org/bulletins/bull16.html#SEC13

[2] Improving IPC by kernel design
    Jochen Liedtke
    SOSP December 1993
    http://portal.acm.org/citation.cfm?id=173668.168633

[3] Workplace Microkernel and OS: A Case Study
    Brett D. Fleisch and Mark Allan A. Co
    Software--Practice and Experience
    May 1998
    http://portal.acm.org/citation.cfm?id=279869.279875

[4] A Critique of the GNU Hurd Multi-server Operating System
    Neal H. Walfield and Marcus Brinkmann
    ACM SIGOPS Operating Systems Review
    July 2007
    http://portal.acm.org/citation.cfm?id=1278901.1278907




reply via email to

[Prev in Thread] Current Thread [Next in Thread]