On Fri, 29 Sep 2006 10:31:36 -0600, Anne & Lynn Wheeler wrote: > >[EMAIL PROTECTED] (Tom Schmidt) writes: >> For zSeries to do it you would either be looking at creative use of MIDAW >> to read/write the 1M pages from/to existing DASD (with less-then-ideal >> performance) or you would be looking at new DASD (or son-of-DASD maybe). >> Perhaps it would be a good excuse to resurrect expanded storage (ESTORE) >> with an also-resurrected Asynchronous Page Mover (of 1M)? > >in the early 80s ... "big pages" were implemented for both VM and MVS. >this didn't change the virtual page size ... but changed the unit of >moving pages between memory and 3380s ... i.e. "big pages" were >10 4k pages (3380) that moved to disk and were fetched back in from >disk. a page fault for any 4k page in a "big page" ... would result >in the whole "big page" being fetched from disk. The MVS implementation followed the work of an SE locked away in a small office deep within IBM Gaithersburg, didn't it? He implemented the block paging algorithm for MVS/SE via an FDP and supported it fairly nicely all by himself. I don't recall his name off-hand, although Richard (mumble- something) seems to ring half-a-bell with me. >note the original extended store ... wasn't so much an architecture >issue, it was a packaging/technology issue. 3090s needed more >electronic store than could be packaged within the proscribed latency >of cache/memory fetch. the approach was to place the storage that >couldn't be packaged for close access ... on a different bus under >software control that burst transfers in (4k) page size units >... rather than the smaller cache line size units ... and then >leverage the programming paradigm already in place for paging to/from >disk. When I lived in POK I was told that a part of the reason for extended storage also had to do with its lack of requirement for storage protect key arrays. The extended storage memory was then allowed to be more like the memory of the competitors in terms of cost, structure & simplicity. (By the early 1990s the competition was considered to be HP, not Amdahl nor HDS). >this is somewhat LCS from 360 days (8mbytes of 8mic storage >... compared to 750ns storage on 360/67 or 2mic storage on 360/50). >the simple strategy was to just consider it as adjunct of normal, >faster storage and tolerate the longer fetch cycle. howeer, some >installations tried to carefully allocate stuff in LCS ... that were >lower use programs and/or purely cached data (like hasp buffers). >however, some installactions actually implemented copying programs out >of LCS to faster storage before execution. One thing that struck me as odd during the entire 1990s was the fact that LCS from 360 days was allowed to be shared between 360/50s or 360/65s and yet that concept of a large storage buffer shared across processors was not considered for extended storage on the 3090 (or ES/9000). It seemed like IBM forgot. I never considered the coupling facility to be an analog of LCS... I don't know of any analog of LCS since LCS.
-- Tom Schmidt Madison, WI ---------------------------------------------------------------------- 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
