Rob van der Heij wrote
The mini disk is an imperfect (but cheap) implementation of a low
level abstraction. The main "defect" is the number of cylinders, but
for many purposes the virtualization is good enough because the guest
can live with that.
But at considerable additional cost, VM could have been designed to
span a mini disk over multiple volumes. With such support, you could
give out more perfect 3390's (i.e. not being restricted by the actual
models on the hardware). And VM could have played tricks not to
allocate real disk space for unused tracks. This is exactly what was
done in the RAMAC Virtual Array.
re:
http://www.garlic.com/~lynn/2007f.html#20 Historical curiosity question
some long winded topic drift ...
as undergraduate i had done a lot of modifications to the cp67 kernel
... a lot oriented towards significantly improving pathlength for
os360 guest virtual machines, new resource management algorithms, and
dynamic adaptive resource control.
I had also looked at doing some stuff for CMS ... one of the things I
realized that CMS was simulating the operation of doing syncronous
disk transfers with overhead of sio/lpsw-wait/interrupt paradigm. so i
defined a new CCW opcode that would do syncronous disk transfers
... and the virtual machine would get back CC=1, csw stored on the SIO
operation ... indicating the operation had already completed.
This i got somewhat slammed on by the people at the science center as
having violated 360 machine architecture and principles of
operation. Eventually it was explained that it would be possible to
use the 360 "DIAGNOSE" instruction to implement such "violations"
... since the principles of operation defined the DIAGNOSE instruction
implementation as model dependent. Define an abstract 360/"virtual
machine" model and the way that the DIAGNOSE instruction work for that
"model". However, the pathlength improvement for the change was pretty
significant ... so the syncronous disk transfer operation was
eventually re-implemented with DIAGNOSE instruction.
Later when I joined the science center ... one of the things that i
did for cp67/cms (that never shipped in the product) was the cp67 and
cms changes to support page-mapped filesystem operation. This
was combined in general set of stuff that I referred to as virtual
memory management. Later it was some of the stuff that was ported
to vm370 ... old communication with reference
http://www.garlic.com/~lynn/2006v.html#email731212
a small subset of the virtual memory management stuff made it out in
vm370 as DCSS (but not the page mapped filesystem stuff or a lot of
other stuff) ... recent post
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology
Note that even with the DIAGNOSE operation there was still a lot of
overhead related to emulated channel programs that require real
addresses for execution (shadows of the virtual channel program
created with real addresses of the virtual pages which have been
pinned in real storage). This is not only true for virtual machine
emulation ... but anything that has applications building channel
programs in a virtual address space. For reference, posts about
originaly prototype OS/360 to VS2 virtual memory operation by
hacking a copy of cp67's CCWTRANS into the side of MVT (to create
translated, shadow channel programs with real address and pinned
virtual pages)
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems
history
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems
history
so the page mapped filesystem support, changes to both cp67 to provide
the DIAGNOSE instruction API) and changes to low-level CMS filesystem
function to use the cp67 API (pretty much leaving the high-level CMS
filesystem interfaces "as-is") ... eliminated most of the rest of this
channel program translation overhead gorp. It also moved the CMS disk
paradigm interface even beyond the simplifications possible with FBA
disks.
Having drastically simplified the disk paradigm interface ... the
implementation of a lot of other features became significantly easier.
For instance, it was possible to dynamically adjust how requested page
transfers were actually performed being able to dynamically do either
syncronous transfers and/or even asyncronous transfers (transparent to
the syncronous CMS virtual machine paradigm by fiddling the page
invalid bits).
The simple, original implementation just mapped a set of contiguous
page records ... to contiguous cylinders supported leveraging existing
minidisk definitions. However, it also become extremely
straight-forward to do other types of enhancements (having removed the
binding for the cms virtual machine to explicit ckd disk hardware
characteristics), like having multiple sequentially chained blocks of
pages ... at discontiguous locations on the same or different disks
... emulated a single set of (contiguous) page records (aka enabling
relatively trivial implementation support for various kinds of
cms filesystems spanning multiple disks).
A lot of this is analogous to the features that showed up in more advance
controllers and the logical volume manager (LVM for unix systems being
able to specify filesystems as possibly multiple discontiguous groups
of records ... either as concatenated discontiguous allocation or
various kinds of RAID operation).
lots of past posts mentioning (cms filesystem) page mapped work
http://www.garlic.com/~lynn/subtopic.html#mmap
I also later leveraged the kernel diagnose API for page mapping to do
a prototype implementation that moved the cp spoolfile system into a
virtual address space. part of it was I needed to speed up spool file
thruput for the vnet/rscs virtual machine by a couple orders of
magnitude to correspond with the high-speed backbone work ... misc
posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and misc. pasts posts mentioning the spool file system prototype
work
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device
(was Re: removal of paging device)
http://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long
post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format
(long post)
http://www.garlic.com/~lynn/2003b.html#46 internal network drift (was
filesystem structure)
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or
nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#3 History of C
http://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before
the ANSI C standard
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#46 Various kinds of System reloads
http://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
http://www.garlic.com/~lynn/2006.html#35 Charging Time
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and
brain-dead OS's?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old
days?
