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/
