Post by Anne & Lynn WheelerFor relocate shared segment support, a shared segment may appear
anywhere within a virtual machine's address space (it does not need to
be at the position specified in the VMABLOK). The way I handled it in
DMKVMA was to use the PTO pointers in the VMABLOK to check the shared
segments, rather than using the segment index number to displace into
the segment table and pick-up the STE.
One of the co-op students that helped me write the original shared
segment support for release 2 VM (included the sub-set that is now in
the product DCSS) is now with Interactive Data Corporation (IDC). They
have taken the idea and put a whole group on expanding the idea. They
now call it Floating segments (instead of relocating segments). They
have a modified assembler for generating adcon free code and are
working on the compilers. All this work they have done has greater
significance than they realize. It would greatly simplify conversion
to an increased address space size.
re:
http://www.garlic.com/~lynn/2006y.html#20 moving on
and specifically the old email
http://www.garlic.com/~lynn/2006y.html#email790326
and other posts in this thread
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2006y.html#23 moving on
one of the big problems was that the original 370 virtual memory
architecture included "segment protect" feature (i.e. turn on a bit in
segment table entry for a specific virtual address space ... and
everything in that segment became read/only for that address space).
the cp67 to vm370 morph of cms was somewhat structured around having
that feature. i've posted before how the retrofit of virtual memory
hardware to 370/165 ran into schedule problems and they dropped a
number of features from the 370 virtual memory architecture to buy
back six months in the schedule (and then made all other processors
drop them also so that there was compatibility across the 370 line).
this resulted in forcing vm370 to revert to the cp67 convention of
protecting shared pages ... which played games with storage protect
keys. this resulted in addition vm370 overhead for cms ... but a
little later also met than VMA (virtual machine assist) microcode
performance enhancements couldn't be used with shared-system CMS (VMA
implemenation of storage key operations didn't know the rules for
protecting shared segment pages).
preparing for vm370 release 3 ... somebody came up with a hack that
would allow VMA to be used with CMS ... the storage key game was
eliminated and instead the currently running CMS would be allowed to
modify shared pages (as well as being able to run with VMA turned
on). however before switching to a different process, the dispatcher
would scan all shared pages ... searching for ones that had been
changed. If any were found ... they were discarded (new process
requiring discarded shared page would have an unmodified copy
refreshed from disk). The trade-off of reduced overhead being able to
use VMA tended to offset the increased overhead that the dispatcher
had to scan 16 shared pages on (nearly) every process switch.
then it was dediced to pick up a very small subset of my virtual
memory management support (both cp and cms changes) as "DCSS" for
release 3
http://www.garlic.com/~lynn/subtopic.html#mmap
http://www.garlic.com/~lynn/subtopic.html#adcon
this initially resulted in at least doubling the typical number of
shared pages from 16 to 32. However, the overhead of the dispatcher
scanning of 32 shared pages (on every process switch) changed the
overhead trade-off vis-a-vis overhead reduction being able to use
VMA. Somebody then decided they had to go with the change page
scanning hack anyway ... since CMS intensive customers had already
been told that they would get performance benefit in vm370 release 3
with using VMA.
This was further aggrevated when developing multiprocessor support
that would be shipped in vm370 release 4. The change in release 3 for
scanning for changed shared pages was predicated on a single process
having exclusive access to the shared pages at a time. With
multi-processer support, there could be multiple, concurrent running
processes. To preserve the "exclusive access" assumption, it was then
necessary to have processor specific copies of shared pages. Now, not
only did the dispatcher have to scan (and increasing number of) shared
pages for changes (on nearly every task switch) ... but it also had to
make sure that the "switched-to" process had its (virtual address)
segment table entries pointed to the processor specific shared
segments. Now, things were getting entirely out of control.
Another issue that had come up was that the original relational/sql,
system/r had been developed on vm370 and was taking advantage of more
sophisticated virtual memory support. One of the things allowed some
processes address spaces to have r/w shared access to a shared
segments while other processes had only r/o shared access
http://www.garlic.com/~lynn/subtopic.html#systemr
it was referred to as "DWSS" in the technology transfer effort from
SJR to Endicott for what became SQL/DS. few recent posts mentioning
DWSS
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s
Futhermore, the processing load on the US HONE system was increasing
and they were upgrading their 370/168s to multiprocessors ... HONE was
vm370 based infrastructure that provided world-wide support to
marketing, sales, and field people.
http://www.garlic.com/~lynn/subtopic.html#hone
HONE was doing this 6-9 months before release 4 (and official
multiprocessor support) was going to be available.
As i had been involved in a lot of the multiprocessor support
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#bounce
I undertook to build a version of multiprocessor support on their
production vm370 release 3 (which I had heavily modified already).
While, I was doing that, I went ahead and put in the code to revert to
protection games with storage keys (eliminating having to have unique
shared page copies for every processor) that had existing in cp67 and
in vm370 prior to release 3.
for a little drift, pieces of recent thread in comp.arch on virtual
address space mappings
http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006x.html#23 Multiple mappings
http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings
http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
past posts mentioning problem/issues retrofitting virtual memory
support to 370/165
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2000f.html#55 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#10 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#21 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
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/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002.html#50 Microcode?
http://www.garlic.com/~lynn/2002.html#52 Microcode?
http://www.garlic.com/~lynn/2002g.html#47 Why are Mainframe Computers really still in use at all?
http://www.garlic.com/~lynn/2002l.html#51 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#68 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#15 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003g.html#19 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)
http://www.garlic.com/~lynn/2003m.html#34 SR 15,15 was: IEFBR14 Problems
http://www.garlic.com/~lynn/2003m.html#37 S/360 undocumented instructions?
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#53 The mid-seventies SHARE survey
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/2005e.html#57 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005e.html#59 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
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/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2005s.html#23 winscape?
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#12 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#31 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006n.html#16 On the 370/165 and the 360/85
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#1 Is the teaching of non-reentrant HLASM coding practices ever
http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
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/99.html#209 Core (word usage) was anti-equipment etc