On Tue, 14 Jun 2011 11:04:25 -0700, Schuh, Richard <rsc...@visa.com> wrot e:
>A good decision, probably not a difficult one, by Mr. Holder and friends . Untangling that can of worms should not be a high priority use of development $$. > >Regards, >Richard Schuh > There are, of course, other reasons one might want this (or similar) function, such as supporting paging devices with dramatically different response times and bandwidths - load balancing new outbound writes which we already do) isn't really sufficient for such a scenario - in order to prevent the fastest devices from filling up with the oldest data over time, a migration function would be required to move those now older pages off to slower devices (since they're not being re-referenced, you really don't want them taking up space on the faster devices). Also, the real design issue is that there's simply not enough "real estate" to maintain backward pointers up the structures in order to be able to easily determine, from a paging "slot" (4K record) on a paging volume back up to the owner of the page it contains - the storage overhead becomes astronomical rather quickly, and you don't want to be spending lots of storage representing things that are themselves paged out. So the only way to find the pages is to run all of the translation structures for all virtual storage "from the top down" scanning for them (this is indeed how expanded storage migration works, which is why ATTACH XSTORE often takes so long). One further comment on the idea of "bootlegging" the migration function by touching user pages - it's not just user pages that are out there, it's quite likely that the target paging volume also contains some pageable CP owned pages (especially PGMBKs), some of which are simply not "touchable" by any action from a guest. So even if you could figure out which users had pages on the volume, it would still likely be impossible to get all of the pages off of it. Anyway, there are long standing requirements open for the drain migrate function, we know it would be useful, but thus far, there have always seemed to be more pressing needs. Bill Holder, Senior Software Engineer IBM z/VM Development, Memory Management, Endicott, NY Phone: 607-429-3640
