🚀 go-pugleaf

In article <2859@sdcsvax.UCSD.EDU> johnl@ima.ISC.COM (John R. Levine) writes:
>In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes:
>>"very slow memory").  With large address spaces and virtual memory, who
>>needs files?  Why not define all storage as extended memory structures
>>that may be loaded as needed.  ...
:
>
>This is a great idea.  In fact, it's such a great idea that it was first
>implemented in the late 1960s under Multics, which indeed does all of its
>file I/O by mapping the files into the address space.  The IBM System/38
>also has a single-level-store architecture, with all memory and file objects
>having a uniform addressing scheme.  Even the RT PC was supposed to do its
>file I/O through the pager, but we kind of wimped out.  It seems to me that
>considerable performance gains should be obtained this way, because the path
>from the program to the I/O supervisor via page faults should be faster than
>that through system calls -- no user arguments to validate.
:
>
>-- 
>John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
:
Another way to approach this is to leave the files with a separate
existence, but to structure the (file description tables or whatever the
system calls them) such that the file can be mapped to virtual memory.
Then provide the operating system with a call to MAP a file to process
memory.  Both the old IBM TSS operating system (R.I.P :-(   ) and the 
still current CDC VSOS operating system have this feature.  It works
very well and is a very efficient way of doing I/O.  The FIRST call to
open the file goes through a system call, after that file access is
to memory (and via the PAGER when necessary).  This is a very clean,
simple, intelligent way to get very good RANDOM I/O performance.

There is one minor problem however.  Most operating systems read ahead
when doing sequential I/O.  Programs which read large amounts of data
sequentially ( a lot of programs) will suffer a serious negative impact
if this case is not handled properly.  One way is to put code in PAGER
to read ahead.  In order for this to work efficiently, PAGER needs to
be able to distinguish regular virtual memory from sequential file
memory.  This is an additional complication, though it can be (and was,
for some versions of TSS) done.
An additional (not mutually exclusive) way is to provide an operating
system call to ADVISE the PAGER which virtual memory (which may be files or
just regular process memory) will be needed in the near future.  VSOS has
this good feature, and I think it is a good feature to make available
on any virtual memory system.  Since the advise is a system call, you
lose a little bit, though typically less than with non-mapped I/O, since
the ADVISE is asynchronous.  If this approach is taken, the I/O library
needs to keep track of how much data it is using and issue the ADVISES for
itself.


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")