Re: ancient OS history, ARM is sort of channeling the IBM 360

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Work out the numbers. The CPU time necessary to copy a single record is
most likely a small fraction of the time it takes to service an I/O
interrupt.
>
And this is not taking into account the fact that I/O interrupts run at a
higher priority than user-level tasks like copying buffers, anyway.

back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used ... as result a normal/typical 1mbyte 370/165
only ran four regions concurrently, insufficient to keep system busy and
justified. adding virtual memory, could run MVT in a 16mbyte virtual
address space (aka VS2/SVS, sort of like running MVT in cp67 16mbyte
virtual machine)... increasing number of concurrent running regions by
factor of four times (up to 15) ... with little or no paging.

however, created different overhead (in part because the FS failure gave
page-mapped filesystems a bad reputation) ... application filesystem
channel programs were created (usually) by library routines in
application space ... and the channel programs passed to EXCP/SVC0 for
execution, now would have virtual addresses (rather than real required
by I/O system) ... this required EXCP/SVC0 make a copy of every channel
program, substituting real addresses for virtual addresses (initially
done by crafting CP67's "CCWTRANS" into EXCP/SVC0).

370 systems getting larger then were then banging against the concurrent
region 15 limit imposed by the 4bit storage protection scheme keeping
regions separated and had to transition from VS2/SVS single address
space to VS2/MVS where every region was isolated in its own separate
address space.

However, MVS was increasingly becoming quite bloated (also EXCP/SVC0
still had to make channel program copies) and device redrive (device
idle between interrupt to starting next queued request) was a few
thousand instructions. I had transferred to SJR and got to wander around
datacenters in silicon valley including bldg14&15 (disk development and
product test) across the street. They were doing prescheduled, 7x24,
stand-alone testing and had mentioned they had recently tried MVS, but
in that environment, MVS had 15min mean-time-between failure (besides
its significant device idle waiting for device redrive) requiring manual
re-ipl/reboot (aka test devices frequently violated all sort of rules &
protocol). I offered to rewrite I/O supervisor to make it bullet proof
and never fail allowing any amount of ondemand, concurrent testing
... improving productivity (as well as cutting to a couple hundred
instructions between taking interrupt and redriving device).

--
virtualization experience starting Jan1968, online at home since Mar1970