[email protected] (Tom Marchant) writes: > Are you suggesting that before DB2 references a page containing a > buffer, it checks to see if it is paged out? And that if it is paged out, > it doesn't use the record in the buffer, but instead reads it into a > different page? That makes no sense to me.
there is separate problem that i've repeatedly pontificated about since the 70s ... originally involving running MVS in VM370 virtual machine. If VM370 is running a "LRU" (least recently used) replacement algorithm and MVS (in virtual machine) is running a "LRU" (least recently used) replacement algorithm ... then MVS will tend to select to replace and use a virtual machine page that hasn't been used in a long time ... which is also the page that vm370 will have chosen to have replaced and paged-out. LRU recently used algorithm assumes that a page that hasn't been used for a long time is the most likely not be used for a long time in the future. However, if a LRU is running in memory space managed by a LRU algorithm ... then the 2nd level LRU is likely to choose the next page to use ... the exact same page that the lower level LRU has removed from storage .... a virtual LRU algorithm starts to look like MRU algorithm, aka the least recently used page becomes the page that is most likely to be used next (as opposed to the least likely to be used next). past posts mentioning page replacement algorithm http://www.garlic.com/~lynn/subtopic.html#clock I was also involved in the original sql/relational implementation, System/R ... some past posts http://www.garlic.com/~lynn/submain.html#systemr which was done on 370/145 running under VM370. The issue was that the RDBMS (system/r) running in virtual address space manages its own cache of records with algorithms similar to LRU ... which is running in virtual memory managed by VM370 with an LRU algorithm. Then the next least recently used cache area that RDBMS is likely to use ... is also the least recently used area that VM370 has likely to have been replaced & removed from real memory (a LRU managed area running in a virtual memory LRU managed area, will violate assumption that the least recently used area is the least likely to be used in the future and can be replaced). trivia, managed to do System/R technology transfer to Endicott for SQL/DS "under the radar", while the corporation was pre-occupied doing the next official follow-on DBMS "EAGLE". Then when "EAGLE" effort imploded there was request for how fast could SystemR/SQLDS be ported to MVS ... which is then later announced as DB2 (originally for decision support *ONLY*). DB2 will have its own area for caching DBMS records ... managed with a LRU-like algorithm ... running in an MVS virtual memory managed with an LRU-like algorithm ... assuming the least recently used DB2 cache area is then the least likely to be used in the future and can be removed from processor memory. When Jim Gray leaves for Tandem ... he palms off some number of things on to me ... included DBMS consulting with the IMS group ... old email http://www.garlic.com/~lynn/2007.html#email801016 and recent long-winded post (facebook IBM discussion) about Jim Gray (after he left for Tandem) and page replacement/management algorithms http://www.garlic.com/~lynn/2017d.html#52 Some IBM Research RJ reports At DEC81 ACM SIGOPS, Jim asks if I could help a tandem co-worker get his stanford PHD that involves quite a bit of "global LRU" ... and some "local LRU" forces were pressuring his thesis advisor to not approve the work. I had done a lot of work on page replacement as undergraduate in the 60s ... including "global LRU" about the same time there were academic papers on "local LRU" were being published in ACM Communications ... and I had direct apples-to-apples comparisons between "global" and "local" ... showing "global LRU" was significantly better than "local LRU". Unfortunately IBM research management prevented me from responded for nearly a year (even tho the work had been done before joining IBM) ... possibly thinking they were punishing me (which would be better than they were doing it because they were taking sides in the academic dispute). finally was able to send response the following Oct. http://www.garlic.com/~lynn/2006w.html#email821019 trivia: I was being blamed for online computer conferencing (precursor to discussion mailing lists like ibm-main as well as social media) on the IBM internal network (larger than arpanet/internet from just about the beginning until sometime mid-80s) in the late 70s and early 80s ... folklore is that when IBM corporate executive committee was told about online computer conferencing (and the internal network), 5of6 wanted to fire me. i.e. IBM management may have considered that blocking my response for nearly a year was part of punishment for doing online computer conferencing. some past posts http://www.garlic.com/~lynn/subnetwork.html#cmc not getting fired for online computer conferencing ... was possibly partially because one of my hobbies was doing enhanced operating systems that lots of internal datacenters ran ... including the internal, online world-wide sales&marketing support HONE systems ... past posts http://www.garlic.com/~lynn/subtopic.html#hone other trivia: the stanford thesis advisor went on to be president of stanford past posts in this thread: http://www.garlic.com/~lynn/2017d.html#58 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#61 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#63 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#65 Paging subsystems in the era of bigass memory -- 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
