> Have the presenter review ancient history in the S/360 line -- the 360 > line > generally supported differing page sizes (2K and 4K) and the 360/67 > supported 2K, 4K and even 1M page sizes. (I don't recall whether any SCP > shipped that dealt with 1M page sizes, especially in the VERY expensive > storage era of the S360 line though. That could be why the idea lurked > for > lo these many years.)
S/360 didn't have page sizes since there were no pages, because there was no virtual storage. The support for 2K and 4K pages occurred on S/370 with VS1 and VS2. I'm not entirely sure why anyone would think a 1MB page size is beneficial in any way. It would arbitrarily increase the cost of data transfer with no tangible benefit. If the storage were already being frequently referenced, then block paging would group contiguous pages together and "block" then for a more adjustable benefit. Using 1MB sizes would presume that there is enough references to warrant grouping so a large number of pages together. Unless you're seeing large paging "blocks", there is no support for the notion that larger page sizes would be either more efficient or better performers. I suppose an argument could be made that larger page sizes would reduce the amount of storage necessary to back allocations (i.e. page tables). If there is little real page movement to DASD, then the trade-off may be worth it in reducing the cost of managing large working sets. Adam ---------------------------------------------------------------------- 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
