Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg
From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: the Multics from the black lago
Message-ID: <PCG.90Feb11210841@rupert.cs.aber.ac.uk>
Date: 11 Feb 90 21:08:41 GMT
References: <90@<KHB> <76700129@p.cs.uiuc.edu>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 49
In-reply-to: gillies@p.cs.uiuc.edu's message of 9 Feb 90 04:50:00 GMT

In article <76700129@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:

   Re:  Is mapping files into memory a big win?

   Here's a cult-favorite paper that addresses this question,

   "Hints for Computer System Designers", by Butler Lampson

   I can't remember the source (probably ACM SOSP), but it came out in
   1985, and Lampson (formerly at PARC) argued that simple is sometimes
   better.  The Pilot OS designers copied the Multics file mapping trick,
   and later lived to regret it.  The kernel code eventually ate up about
   11,000 lines, and the applications programmers never recouped this
   huge kernel investment.

But the Pilot paper makes it very clear that the implemented the
most complicated possible form of single level storage. It can be
said that it was a colossal mistake. From this deducing that
single level storage is a bad idea is a huge leap.

I would also like to point out that many current Unix
implementations of memory mapped files, most notably the SUN one,
are hopelessly misdesigned from a simplicity and performance
point of view.

For two of the most revolting aspects of the SUN design, let me
point out the 8Kb page size (when virtually all Unix files, and
most obviously directories, are far smaller than that), and the
inability to properly advise the pager (there is a minimal
facility for this, but then programs like 'cp' do not use it)
about non wroking set like reference patterns for regions of
address space, e.g. of the desirability to have read-ahead and
free-behind on sequential accesses, etc...  These two problems
may well account for 90% of the increased memory requirements of
SunOS 4, in the form of uselessly bloated working sets and vastly
increased internal fragementation.

Not to speak of paging strategies, cold starts, dynamic linking
overheads, and other bogosities.

The original Unix design was carefully tuned for PDP-11s, and
extracted very good performance out of very limited hardware and
architecture. A complete overhaul is needed now, but we are not
even up to the level of Multics, not to mention progress after
that.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk