Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Architectural Requirements for Unix (was: upgrades)
Message-ID: <2286@crdos1.crd.ge.COM>
Date: 31 May 90 18:51:22 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> <383@garth.UUCP>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 66

In article <383@garth.UUCP> fouts@bozeman.ingr.com (Martin Fouts) writes:

| 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

  This can be done with segments, too. As long as the code is pure it
can be shared.

| 2) Using copy on write sharing of forked images

  This can be done with segments, too, at least for the segment as a
whole. It's marked read only, then the fault is used to force the copy.

| 3) Using explicit sharing of library code

  This could be done with segments, although I don't know of any machine
which does it. I looked at doing it on a 286, with all the library
routines called with far calls to a library segment. I am sure it can be
done, but I don't have an example of doing it.

| 6) Using copy on read to implement lazy evaluation

  I believe you can do that with segments, too. You certainly can have
separate read and write bits for a segment and turn off both read and
write, then copy on fault.

| 7) Using remapping to implement data transfer where possible

  ??? I think you can do this, but I am not totally sure what you have
in mind. Obviously shared memory works in segmented systems, and the
data does not need to be at the same segment number in each process.
| 
| 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.

  Most of the segmented CPUs, Intel for sure, have 32k or 64k segments.
That certainly covers a lot of ground.
| 
| 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.

  Even running a job which *can* fit in physical memory, I often see
that the working set is smaller than max. Often there is some startup or
wrapup code which doesn't stay in memory, some strings, like error
message, etc.

  In many cases, where the order of data access is not easily
determined, virtual memory will be faster than using i/o to bring the
data in from a file. There will *always* be a program which uses a data
set larger than physical memory, and applications which could
legitimately use more address space than they have.

  In spite of that, I believe that 95% of all programs on all computers
(by number rather than CPU cycles) will run in 4MB of address space.
And probably 95% in 16MB. There are not a lot of applications which
need the huge memory, and that means a small market, few vendors, high
prices, etc. Adam Smith walks here, too.

-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me