> Hi, People. > My cent to this discussion. > We are talking about pages on dasd, not pages in memory. > So, these pages already was swapped. Except some control pages, I think. > > To free the dasd, VM will need: > Know what pages are on the specific dasd. It can be done by "Page out" > routines, updating one table. > Drain the dasd, to prevent new allocation > Put on the bit to force a "Page In" for the pages on that dasd. Returning > to normal page process. > After some time, no pages are on this dasd. It can be purged from the page > tables, removing the control pages. > > Of course, it is not so simple to implement, but looks like viable. > What do you, the experts, think about? > ______________________________________________ > Clovis
Hi Clovis - I'm not sure I completely follow what you're proposing, but I believe I already covered it (though maybe I wasn't very clear). What you describe seems similar to the design approach I suggested. The challenge is this: There is is only one way to do your first step "Know what pages are on the specific DASD"; that is to scan all pages in all pageable spaces using CP's translation tables to determine whether each page is on that DASD. Once all pages on the DASD have been located, moving them is easy enough. Finding them is the hard part. The problem is that there is no way to get from the structures representing the 4K records on the DASD (the paging slots containing the pages) back to the structures which tell us what page is in each slot. All we have to represent each paging slot is one bit (allocated or not) in a bitmap, there is no room for a back pointer to the description of the page that the slot contains. So we have to find the pages the other way - from the top down, scanning all pages in the system to check if they are on the volume in question. This is not a small effort. You might ask why we don't just add that missing back pointer; it seems easy enough. It would indeed be easy enough to code, but the cost in terms of the additional storage usage to hold all of those pointers would be prohibitive - for a maximum sized paging system using ECKD volumes pushed to today's supported limits (about 11TB of paging space), it would mean at least an additional 22GB of non-pageable central storage usage just to hold those back pointers - for a function that is only very rarely used. Using a more real-world example: if you have a 32GB system with a 4:1 overcommit ratio of total virtual to real, with paging configured according to recommendations, those back pointers would take up at least 512MB of non-pageable central storage. It just seems excessively wasteful to spend that much central storage resource representing things that aren't even in storage, especially when it's only needed on a very rare basis. - Bill Bill Holder, Senior Software Engineer IBM z/VM Development, Memory Management, Endicott, NY Phone: 607-429-3640 IBM TieLine: 620-3640 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
