Virtual memory implementation in S/370
(I wrote) >>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. (someone else wrote) > Actually, z/Architecture has 5 levels. So far, > the existed hardware only uses 3 of them. I thought of that right after sending it. Above the addressing within a page, it is, more or less, 10 bits per level. (For S/370, one could consider the 32 bit addressing for the 360/67, which is fairly similar.) For an undergrad operating system course I did a report comparing S/370 and VAX virtual memory systems (around the time when VAX was new). I remember finding more similarities than differences, especially both using the two level system. So for 64 bit addressing of 4K pages, (64-12)/10 is about five. Allowing the hardware to use three until more addressing bits are needed is a nice feature. -- glen
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
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. 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
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/
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