> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Greg Dyck > Sent: 18 April, 2017 15:58 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > On 4/18/2017 2:25 AM, Vernooij, Kees - KLM , ITOPT1 wrote: > > As I said, I remember reading this a long time ago, I don't know the > details anymore, whether the source was reliable and whether it is still > working this way. Only a DB2 internal expert should be able to tell. > ... > >> On 12 April 2017 at 10:16, Tom Marchant < > >> 0000000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> [DB2] > >> > >>> So, if it thinks it would be faster to read the record from DASD > than > >> for > >>> MVS to page in the buffer page(s) containing the record, it will > read > >> the > >>> record into different pages that have not been paged out? > > While the DB2 buffer manager code does collect statistics on the > frequency of buffer pages being latched that are currently paged out > (using TPROT), I don't remember seeing any logic to reread a buffer page > vs waiting for a demand page-in to occur in the code. And given that > the current copy of a page may be the one in the buffer pool, rather > than on the copy on DASD, and that multiple threads can have shared > ownership of a buffer pool page, I do not believe this processing exist > (at least for the last 15 years) in DB2. > > 30 years ago this type of logic, to reread from DASD rather than demand > page-in a buffer page, *might* have made sense, when the I/O bandwidth > to the paging subsystem was limited based on the number of page datasets > and a demand page rate of 30-100 pages a second was common to see. But > the world has changed and it would not make sense to do it today. > > Regards, > Greg >
Thanks Greg. ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
