The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[email protected] (Tom Marchant) writes: > Part of the reason for the paging problem was that the architecture did not > have a fixed page size. It was a bit-oriented machine and memory could be > allocated to the bit, without any regard for byte boundaries. Even the > instruction counter was a variable size, depending on the memory > requirements of the program. Depending on the size of the program, the page > size could be any power of 2 -- 4K, 1K, 8K, 256 bytes, etc. It made finding > an available page a difficult task, especially on a machine that was memory > constrained. 370 had 2kbyte & 4kbyte page sizes (as well as 64k & 1mbyte segment sizes). but, in general there weren't systems changing from one size to another ... it selected one size and stuck with it ... aka dos/vs, vs1 used 2kbyte pages ... and VM & MVS used 4kbyte pages. a possible caveat was VM "shadow" tables ... were whatever the virtual machine was using. one of the things that Endicott tried to do with ECPS on 370 138/148 was to turn it into a vm370 "only" machine ... i.e. vm370 would be shipped as native part of the hardware ... somewhat like LPAR is today. With ECPS on 148 ... there was situations were VS1 actually run faster on vm370 on 148 ... than w/o vm370. The issue was that 2k pages had advantage in very small real storage ... but by 138/148 ... real storage sizes had significantly increased. VS1 under vm370 ... with VS1 "handshaking" ... VS1 created a 16mbyte virtual address space tables (using 2kbyte pages) that ran in a 16mbyte virtual machine. The ersult was that VS1 never had requirement to page ... and vm370 did all the paging in 4k pages (instead of VS1 doing it in 2k pages). With handshaking, VS1 could do a task-switch while vm370 was handling a page fault for VS1 virtual machine (and vm370 4k page i/o handling was significantly more efficient than VS1 2k page i/o handling). in any case, for various reason ... corporate hdqtrs overruled endicott shipping 138/148 as vm370 machines (with vm370 installed before it left the plant). now there was some customer problems for vm370/vs1 customers moving from 168-1 to 168-3. big speedup for 168-3 was doubling the cache size. to do this ... they used the "2k" address bit for cache line indexing. To avoid duplicates ... when running with 2k page tables ... the 168-3 dropped backed to only using half the cache. whenever the 168-3 switched between 2k page mode and 4k page mode ... it also did a complete cache flush. Now, even tho vm370 did all paging in 4k mode ... when the vs1 virtual machine was running ... it used 2k page "shadow" tables (that emulated the vs1 page tables) ... but would switch to 4k page mode (and the virtual machine tables) whenever the vm370 kernel was entered. The result was heavy vm370/vs1 customers actually saw performance degradation when they moved from 168-1 to 168-3 (since the double sized cache was never used when vs1 was running and there was a lot of additional hardware overhead constantly flushing the cache switching back & forth between vs1 virtual machine and the vm370 kernel). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
