On Friday, 11/03/2006 at 07:54 CET, Mark Perry <[EMAIL PROTECTED]> wrote: > The explanation does however lean on z/VM's algorithms as being the > potential need for Expanded storage, and the 2GB problem went away with > z/VM 5.2. > > An OS that need to cache "active" working sets, only needs to do so when > it runs out of sufficient Central storage. By moving Central storage to > Expanded storage one only exacerbates the problem.
Trust us, Mark. Yes, there is a pivot point where the system will page into expanded storage without going to disk, but that's a razor's edge. When you blow past it and begin to page to dasd, you will find that the expanded storage helps mitigate the imperfect decisions CP makes w.r.t. the pages he chooses to send to page out. Our Collaborative Memory Management solutions help address this problem as well. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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
