Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!uakari.primate.wisc.edu!dali!milton!uw-beaver!Teknowledge.COM!unix!garth!fouts@bozeman.ingr.com (Martin Fouts)
From: fouts@bozeman.ingr.com (Martin Fouts)
Newsgroups: comp.arch
Subject: Re: Architectural Requirements for Unix (was: upgrades)
Message-ID: <383@garth.UUCP>
Date: 30 May 90 16:22:40 GMT
References: <29972@cup.portal.com> <1990May14.141148.9884@xavax.com> <7754@crdgw1.crd.ge.com> <30016@cup.portal.com> <1990May19.230618.16090@utzoo.uucp>
Sender: fouts@garth.UUCP
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 72
In-reply-to: henry@utzoo.uucp's message of 19 May 90 23:06:18 GMT

In article <1990May19.230618.16090@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

   From: henry@utzoo.uucp (Henry Spencer)

   In article <30016@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes:
   >When I asked about the difficulty of running Unix on the 376, which only
   >has segmentation, not paging, but is in other ways similar to the 386,
   >I meant running full-blown demand-paged virtual memory...

   Who needs paging?  Keep your programs down to a sane size and segmentation
   will amply suffice, especially on a single-user machine.  Of course, very
   few of today's Unix programmers know how to make programs small and fast,
   so this won't work too well in practice.

There are at least four wrong assumptions which the naieve might read
into this paragraph:

1) Segmented memory machines have smaller memory/process than virtual
   memory machines.  This is not always true.  The Cray 2, for example
   is a    segmented memory machine and I've run 0.99 gigabyte
   processes on it.  (Others have since run larger...)

2) Virtual memory implies larger processes.  Not true.  Trading memory
   against performance in a virtual memory system may mean larger
   process images.  However, if they have good locality of reference,
   it might mean smaller memory resident set sizes.

3) Smaller is "better".  If I have to solve a 1000^3 grid, I have to
   solve it.  I've done it with segmented memory in the small (Y/MP)
   and segmented memory in the large (Cray 2) and virtual memory
   (ETA/10.)  For my purposes, the Cray 2 was best.  Your milage would
   vary.

4) The main reason for using virtual memory is to allow a small
   physical memory to support a large process image size.  This is the
   worst reason for using virtual memory.  The main reason for using
   virtual memory is to make programs easier to write.

The advantages of text/data sharing, small resident sizes, and
implicit memory management are enough to justify the cost of tlbs,
mmus and slower memory accesses in a lot of cases.

I need paging.  I need it to keep the total amount of memory I am
using small and make my programs more efficient by:

1) Using implicit sharing of text segments
2) Using copy on write sharing of forked images
3) Using explicit sharing of library code
4) Using explicit sharing of multithreaded applications
5) Using good locality of reference to minimize resident sets
6) Using copy on read to implement lazy evaluation
7) Using remapping to implement data transfer where possible

I do it with paging rather than segments because there ain't never
enough segments on a segmented system, and many segmented systems
don't have the architectural support to ease implementations of some
of the featues.

I *never* use virtual memory to make a small memory look large,
because I can't afford the performance hit from the paging activity,
and feel sorry for those who must take it.

So, the answer (in part) to the question "Who needs it?" is I do.
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts  ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

If you can find an opinion in my posting, please let me know.
I don't have opinions, only misconceptions.