Is VIO mandatory?

[Anne & Lynn Wheeler]

***@ibm-main.lst wrote:
> I wonder about teD's statement that there remains a performance
> edge for VIO. I understand the paths for paging are highly
> optimized. But with modern buffered and virtual DASD the
> difference ought to be shrinking. And there's the offsetting
> overhead of emulating CKD protocol in virtual memory.

the original prototype for the move from MVT to VS2 ... involved
crafting cp/67's CCWTRANS into the side of MVT (excp processing). the
problem is simulating real i/o operations in a virtual memory environment.

basically excp/svc pointed to channel program. CCWTRANS was called to
scan the passed CCWs, creating a shadow channel program that was
actually going to be executed. each CCW from the original channel
program was copied into the shadow channel program, any referenced
virtual addresses had the associated virtual page fetched (if necessary)
and fixed in real memory, the real address of the virtual page was then
stuffed into the shadow ccw. when CCWTRANS was complete, the shadow
channel program (rather than the passed excp channel program) was
scheduled for executing (the virtual pages were pinned at real storage
so they wouldn't move until after the shadow channel program ... with
real addresses ... had finished)

at completion of the I/O operation, the shadow channel program was
rescanned ... and each virtual page that was pinned in the CCWTRANS pass
was then unpinned.

one of the savings in V=R is that the passed channel program can be
executed directly since all of the addresses are "real" and already pinned.

LPARs are essentially a subset of virtual machine ... with nearly
everything in hardware/microcode. LPAR support can get around the shadow
CCW stuff by slight hack to the hardware i/o support ... and having all
the memory for a LPAR contiguous. then the microcode just has to handle
base/bound relocation of every I/O address (i.e. rather than having to
translate every 4k virtual page to a real address, a fixed offset
address just needs to be added to every LPAR i/o address).

i had originally implemented page mapped filesystem for cms for cp/67
and then ported it to vm/370
http://www.garlic.com/~lynn/subtopic.html#mmap

there were all sorts of savings for the page mapped interface ...
eliminating the scan, shadowed ccws, page fixing, schedule real i/o,
rescan, and unfix, etc (even for cms disk i/o which already had a
fastpath version of CCWTRANs that i had originally done on cp/67 as an
undergraduate).

recent posting on some old comparisons of paged-mapped versus emulating
CCWs ... from a presentation that I had given at the fall '86 SEAS meeting
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP for z/Linux

the topic in this particular thread is similar to VIO discussion
http://www.garlic.com/~lynn/2006.html#17 (SPAM?) DCSS as SWAP disk for
z/Linuz
http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux
http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux

random past postings referring to the original MVT->VS2 work using
CP/67's CCWTRANS
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is
needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was
Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable
operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or
nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities
for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs
above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate
volsers

[Anne & Lynn Wheeler]

Ed Gould wrote:
> I think the 2314 was the original suggestion by IBM.

2314 (29 mbytes) and 2301 (paging drum, 4mbytes) were contemporaries on
360/67 (early 360/67s tended to have 2311 7mbytes before 2314s were
available). there were two drum models, 2303 and 2301. the 2303
read/wrote single head. the 2301 was nearly identical but read/wrote
four heads in parallel (for four times the data transfer rate).

table of some old capacity
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives

the above gives both nominal access/sec/drive as well as normalizing the
access rate by capacity ... giving access/sec/mbyte ... i.e. a 3380
limited to just 40mbyte gives approx. the same access/sec/mbyte as
fully loaded 2314.

"early ibm disk history" (from wikipedia)
http://en.wikipedia.org/wiki/IBM_350

also, if any remembers additional code names, they may be able to help
complete this table
http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)

370s (especially after virtual memory was announced) tended to have
3330-1 (100mbytes) and 2305 (12mbytes, fixed head disk). there were
actually two 2305 models; one with 12mbytes and one with 6mbytes. the
6mbyte model had same number of heads as 12mbyte model but "ganged" and
offset 180degrees (and 1/2 the tracks). it only read/wrote a single head
... but chose the first head that encountered the desired record (and
therefor had 1/2 the avg. rotational delay).

around 1980, a lot of internal sites got "1655". these were emulated
2305s built by a memory chip vendor that used memory chips that had
failed some standard memory chip test. There were enuf useable bits in
the chip that the "1655" controller circuitry was able to compensate for
various failures (at least in i/o transfer operations).

the 3350 had a couple cylinders that could have a fixed-head option. in
the late 70s, i was trying to get a feature added that would provide a
separate "exposure" address to any fixed-head region (to avoid having
fixed-head i/o blocked by 3350 arm motion i/o). this ran into politics
with a POK group that was planning something called vulcan ... basically
something similar to (later) 1655 ... or imagine something like 3090
expanded store but with i/o semantics. they felt that such an enhanced
3350 fixed-head option for paging would compete with vulcan (vulcan was
canceled before announce).

the first kernel to run virtual memory on 370 was a modified version of
cp67. there was a joint project between endicott and cambridge
http://www.garlic.com/~lynn/subtopic.html#545tech

to implement 370 virtual machines (which were similar to 360/67 but
differed in the virtual memory hardware architecture). the basic csc/vm
production cp67 (running on cambridge's 360/67) was "cp67l". the joint
endicott/cambridge project modifications to provide 370 virtual machines
was "cp67h".

the cp67h system rarely ran on the real hardware. the issue was that the
cambridge machine also provided various kinds of time-sharing system to
people at educational institutions in the boston area (had mit, bu,
harvard, etc students). 370 virtual memory hadn't been announced and
there was a real security issue if the cp67h system ran on the real
hardware, 370 virtual memory details might leak. as a result cp67h
tended to only run in a 360/67 virtual machine under cp67l production
system.

once cp67h was operational, then there were modifications to create a
cp67 that ran on 370 virtual memory called "cp67i". a year before the
first 145 engineering model with virtual memory hardware, cp67i was
regularly running in 370 virtual machines under cp67h (which was running
in 360/67 virtual machines under cp67l).

there is old story about when the endicott engineers felt that they
finally had virtual memory hardware ready to test and there was a trip
to endicott with a copy of cp67i. the first boot failed. after a little
diagnoses, it turned out that the engineers had reversed two of the new
"B2xx" op-codes. the kernel was quickly patched to correspond to the
(incorrect) hardware and the system successfully booted.

after that there was period when most of the internal 370s (with virtual
memory support) ran with cp67i (both before and after 370 virtual memory
was announced). early on, there were three disk engineers that came out
from san jose and added the support for 3330 and 2305 ... including
supporting RPS (lots of early 145s had been running with 2314s). cp67i
with 3330 & 2305 support was frequently referred to as cp67sj.

old "cp67i" stories
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

the early VS2 prototype started out with a version of MVT with virtual
memory software support hacked onto the side incorporating a cribbed
version of CP67's CCWTRANS to do the virtual->real channel program
translation.
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory

past posts mentioning the vs2 effort starting with CCWTRANS
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers

adding virtual memory hardware to 370/165 was holding up the whole 370
virtual memory announcement. there was a resolution meeting where the
165 engineers proposed dropping some of the 370 virtual memory features,
which would cut six months off their effort. when this was accepted, all
existing implementations on other models needed the dropped features
deleted.

past posts mentioning posts mentioning difficulty of adding virtual
memory to 370/165.
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack
http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

[Anne & Lynn Wheeler]

***@ibm-main.lst writes:
> Is it necessary to round to a page boundary, or only to a cache line
> boundary? (Either is subject to architectural change.)

what is the objective? ... things like cache line thrashing across
different processors ... or use of page-oriented protection mechanisms
(of course it is usually transparent if program loading rounds up to a
larger storage aligned increment).

it used to be that storage key based protection mechanism was 2k ...
but with 3081 and 370-xa ... 2k storage keys were dropped in favor of
4k storage keys.

and as mentioned ... cms had shared pages in cp67 ... which was
oriented around r/o protection on page basis (using a hack involving
2k storage key protection). in the morph of cms for vm370, some amount
of cms was reworked to align with the segment sharing (across address
spaces) and segment protection facility in the original 370 virtual
memory architecture. the segment protection (and other) features of
the original 370 virtual memory architecture got dropped as part of
buying six months schedule time for 370/165 hardware implementation
(and while the cms programing model retained the shared-segment
alignment orientation ... the underlying protection mechanism used by
vm370 reverted to the storage key based protection mechenism used by
cp67),

and then, of course, there is the whole os/360 heritage of relocatable
adcons ... not only do all the relocable adcons need to be swizzled as
part of program loading ... but it is further aggrevated by
relocatable adcons being intermixed with program code and data (as
aside, cms leverages uses of the os/360 derived assemblers, compilers,
conventions, etc ... however, tss/360 had a much better convention for
the handling of program address constants in a virtual memory
environment).

various recent postings mentioning the relocatable adcon issue
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of the swallaw (was Real core)
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?

and lots of past posts mentioning relocatable adcon issue
http://www.garlic.com/~lynn/subtopic.html#adcon