Virtual memory implementation in S/370 (a.f.c x-post)
The recent thread about virtual memory sparked a (kind of) idle question: why did the implementation in the S/370 have a two-level scheme (segment and page)? My original thought was that it facilitated definition of discontiguous parts of an address space. Well, mostly it is because smaller systems don't have enough real memory to hold a one level page table. The segment/page system allows page tables to be paged out, with the invalid bit in the segment table. VAX uses a two level system where page tables are paged. There is kernel space, which isn't paged and holds the first level tables referencing pagable second level tables. z/Archtecture has three levels. Actually, Region First Table Region Second Table Region Third Table Segment Table Page Table Richard Corak
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp [EMAIL PROTECTED] writes: The recent thread about virtual memory sparked a (kind of) idle question: why did the implementation in the S/370 have a two-level scheme (segment and page)? My original thought was that it facilitated definition of discontiguous parts of an address space. Well, mostly it is because smaller systems don't have enough real memory to hold a one level page table. The segment/page system allows page tables to be paged out, with the invalid bit in the segment table. VAX uses a two level system where page tables are paged. There is kernel space, which isn't paged and holds the first level tables referencing pagable second level tables. z/Archtecture has three levels. -- glen
Re: Virtual memory implementation in S/370 (a.f.c x-post)
On Thu, 11 May 2006 11:08:56 -0700, glen herrmannsfeldt [EMAIL PROTECTED] .edu wrote: Marten Kemp [EMAIL PROTECTED] writes: The recent thread about virtual memory sparked a (kind of) idle question: why did the implementation in the S/370 have a two-level scheme (segment and page)? My original thought was that it facilitated definition of discontiguous parts of an address space. Well, mostly it is because smaller systems don't have enough real memory to hold a one level page table. The segment/page system allows page tables to be paged out, with the invalid bit in the segment table. VAX uses a two level system where page tables are paged. There is kernel space, which isn't paged and holds the first level tables referencing pagable second level tables. z/Archtecture has three levels. -- glen = == == Actually, z/Architecture has 5 levels. So far, the existed hardware only uses 3 of them.
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp [EMAIL PROTECTED] writes: The recent thread about virtual memory sparked a (kind of) idle question: why did the implementation in the S/370 have a two-level scheme (segment and page)? My original thought was that it facilitated definition of discontiguous parts of an address space. 370 virtual memory architecture segment page tables. 360/67 provided for both 24-bit virtual addressing and 32-bit virtual addressing (in its segment/page virtual memory structure). the introduction of virtual memory on 370 was just 24-bit virtual addressing with segment and page tables, originally with 1mbyte and 64kbyte segment options as well as 4kbyte and 2kbyte page options. the original 370 virtual memory architecture also had segment protection and some selective invalidate instructions. these additional features were dropped to help get the virtual memory hardware retrofit to 370/165 back on schedule. in the morph from cp67/cms to vm370/cms, cms had been restructured to take advantage of shared segments (single copy of the same virtual memory page in physical storage for multiple different virtual address spaces) with the segment protect feature. when segment protect was dropped from 370 virtual memory architecture, the protection of these shared pages had to be reworked. more than 24-bit virtual addressing wasn't re-introduced until 370-xa with the 3081. I had done a page-mapped filesystem for CMS, which included compatibility for existing CMS filesystem API http://www.garlic.com/~lynn/subtopic.html#mmap It also included a number of extended features allowing page-mapped objects (shared non-shared) to appear at arbitrary virtual address locations. the same shared (segment) object could even appear at different virtual addresses in different virtual address space. this required a lot of fiddling with the prevalent 360/370 software use of address constants. Lots of posts mentioning the fiddling with address constants http://www.garlic.com/~lynn/subtopic.html#adcon Only a small subset of the virtual memory object support was ever released called DisContiguous Shared Segment (DCSS). The generalized virtual memory object support and the page mapped filesystem support was never released. various posts mentioning the segment protect issue: http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#9 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#10 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004p.html#14 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy http://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware 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/2005f.html#46 Moving assembler programs above the line http://www.garlic.com/~lynn/2005h.html#9 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new? http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access alignment http://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection 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/2006b.html#39 another blast from the past http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? ... and misc. past posts mentioning dcss: http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390 http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) http://www.garlic.com/~lynn/2002o.html#25 Early computer games http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning) http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why? http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software? http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing
Virtual memory implementation in S/370 (a.f.c x-post)
Marten Kemp [EMAIL PROTECTED] writes: The recent thread about virtual memory sparked a (kind of) idle question: why did the implementation in the S/370 have a two-level scheme (segment and page)? My original thought was that it facilitated definition of discontiguous parts of an address space. re: http://www.garlic.com/~lynn/2006i.html#22 virtual memory http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 i had also done page migration as well as table migration ... which were released in my resource manager product ... the blue letter product announcement gives product release as 11may76 ... 30 years ago tomorrow. partial reproduction of the resource manager blue letter: http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager page migration would look make judgements about different speed paging devices ... and if it found high speed paging devices filling up, it would start looking for idle virtual pages (resident on high speed devices), that it could migrate to slower speed devices. when real storage started getting constrained ... it would also look for idle portions of virtual address spaces. each 64kbyte virtual segment consumed ten bytes of real storage, 2bytes for the page table entry and 8bytes of adminstrative stuff (shadow storage protect keys, and location on paging device for the virtual page). for idle segments, it would turn on the invalid bit in the segment table entry, write the administrative stuff to special disk locations, and then discard the real memory for the page table and administrative stuff ... typically picking up 160bytes of real storage per 64kbyte of idle virtual address space or 2560bytes of real storage per 1mbyte of idle virtual address space ... little over 4kbytes of real storage per 2mbytes of idle virtual address space. the defined virtual address space might or not be contiguous ... but the segment table could have large gaps in the pointers to page tables ... potentially because the space wasn't defined in the particular virtual address space ... or because the virtual address space area was deamed to be idle at the moment and the associated tables had been removed from real storage. the administrative table containing the disk backing store address for virtual pages (and the shadow storage protect keys) was called a SWAPTABLE ... so the feature allowing the SWAPTABLE to be removed from real storage was called SWAPTABLE migration or paging SWAPTABLEs. a few other posts mentioning SWAPTABLE migration: 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 http://www.garlic.com/~lynn/2006.html#35 Charging Time http://www.garlic.com/~lynn/2006.html#36 Charging Time ... and a few posts mentioning shadowing process: http://www.garlic.com/~lynn/2005h.html#17 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2006i.html#10 Hadware Support for Protection Bits: what does it really mean? -- Anne Lynn Wheeler | http://www.garlic.com/~lynn/
