🚀 go-pugleaf

In article <1383@atanasoff.cs.iastate.edu>, hascall@atanasoff.cs.iastate.edu (John Hascall) writes:
> In article <26970> davec@cayman.amd.com (Dave Christie) writes:
> }In article <5932> butcher@g.gp.cs.cmu.edu (Lawrence Butcher) writes:
...
> }and wonderful data structures out on disk?  For the latter, the 180
> }architecture, along with the NOS/VE OS, provides what I think is the
> }ultimate(*) in user-level i/o: none!  What I really mean is: implicit i/o
> }via memory mapped files.  Simply associate a file(s) with a data
> }structure(s) in the virtual address space of your software, and 
> }access it anyway you like.  Actual physical i/o occurs simply as
> }part of normal paging.  No fuss, no muss.
> 
>       But since you can also do this in VMS, it is by definition bad. ;-)

I can't give a reference, but I thought that memory mapped file I/O was 
going to be included in one of the future versions of UNIX.  I can't
remember if it will be in OSF or System V.  It is convenient and can
give quite a performance improvement over manual code.  If I'm not
mistaken moving data around manually is usually a lot slower than
using something like the SWAPPER process do it for you.

Since this group seems to have side-tracked itself into a comparison
of the features of various OSes, I will continue the tangent.

We use both VMS and UNIX in our environment.  Although VMS is alleged
to have more sophisticated scheduling algorithms, I can't say that I
have really noticed a big difference.  I like the UNIX automatic
priority decreasing facility.  In my meager understanding of the
algorithms UNIX makes sure that everybody gets some time, no matter
how little.  VMS doesn't seem to do this.  Jobs at priority 3 can
sometimes be stalled completely if there are lots of priority 4 jobs
around.  I would prefer that priority 3 jobs got a little bit of
time.  I also note that most OSes seem preoccupied with managing
memory and CPU load.  This was important in the days of expensive
memory and slow CPUs.  What is often a bottleneck speed is I/O.
For instance, if you want to take over a VMS machines it is quite
easy.  Do a *whole* bunch of small QIOs (queue an I/O request to
a disk drive), but don't wait for the result (eg. do a bunch of
writes but don't block).  Even if the process doing this is at
low priority, it eventually takes over the system.  What happens
is that higher priority jobs will typically need to do occasional
input.  They place their I/O request and the end of the queue, and
block until the I/O completes.  If there are 10000 requests in the
queue, they block for a long time.  Eventually everybody ends up
blocked most of the time except the lower priority (anti-social)
job or jobs which do no blocking I/O.  I speak from experience;
this has happened (accidentally) on our system.

Moving back to comp.arch, I think the point about mainframes and
minis being different from micros and workstations because of the
I/O capacity is entirely correct.  Our Intergraph VAX has special
disk controllers.  Each disk controller is worth (costs?) more
than a workstation, and I haven't even added in the bus to house
the controllers or the disk drives themselves.  For that reason
I think that small single user systems are ideally suited to
simple operating systems like UNIX.  UNIX (and for that matter
VMS) don't effectively manage the I/O subsystems of larger
machines.  IMHO.





-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb