glen herrmannsfeldt <[email protected]> writes: > Some of this is described in the above mentioned web page. > It seems that some improvements have been made along the way. > > Also described is precleaning, where you write out a page in > anticipation of its need for replacement.
re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#27 5 Byte Device Addresses? misc. past posts mentioning page replacement & virtual memory management http://www.garlic.com/~lynn/subtopic.html#clock there were two issues with the early SVS/MVS replacement ... regarding selecting non-changed pages before changed pages ... one was eliminating the work and overhead of the write ... and the other is the issue of eliminating any synchronous latency related to waiting for the write. most implementations early on, implement a pool of immediately available pages for replacement (that had been pre-selected) ... rather than synchronously running the replacement with the selection (immediately available eliminates synchronous latency associated with selection and potential writes). the pool could be also run with min/max ... so when pool of immediately available pages dropped below a min ... it was replenished to the max (trying for some slight efficiency batching selection process). there was also "big pages" starting in the early 80s (done for both MVS & VM) ... that always did writes ... collecting set of pages and doing single write operation for full 3380 track of pages. the issue was that while 3380 transfer rate was 10 times that of 3330 ... the access latency (arm & rotation) only marginally increase. The theory was that the increase in 3380 efficiency always doing full-track writes&reads (single access for full-track of pages) ... offset the increased overhead having to unnecessarily write unchanged pages. This would have further highlighted the downside effects of choosing non-changed before changed that I argued before they first shipped ... and they finally realized in the late 70s. however, the "big pages" selection processing violated LRU in other ways ... this is old email discussing LRU ... including some of how "big pages" undermined LRU: http://www.garlic.com/~lynn/lhwemail.html#globallru -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
