Rob, just so I'm clear on this (prior to z/VM 5.2) a guest needs to page into <2G storage to do explicit disk I/O and that's as true of 31-bit hosts as 64 bit hosts, that's useful to know. What about the contribution to paging from execution of instructions? What I was hoping was that from CP's point of view a page will not need to move below the line if the code path doesn't request disk I/O - so that for "equavalently sized 64-bit hosts" there may be some VM paging reduction depending on the type of work load.
Another point I'm not clear on - is if XSTOR is utilised as a page cache, and CP takes an interrupt to page in from XSTOR (or even from disk), will it bring in a page above the 2G line for 64-bit hosts and below the 2G line for 31-bit hosts? I'm trying to understand why I'm seeing 30-50% storage utilisation with some quite high XSTOR<->MAIN paging and reasonable MAIN/XSTOR <-> disk paging. I though that equivalently sized 64-bit hosts might drive up main storage utilisation and reduce overall paging. John Taylor.
You're mistaken. The bitness of the guest has nothing to do with that. The issue is in the bitness of some code paths in CP that require the page to move under the bar to do things with the data inside. Running the guest in 64-bit will not help you anything (but 64-bit guests have an excuse for bigger virtual machines and thus make it worse). One of the most visible things is disk I/O where CP needs to put the guest data pages under the bar and Linux decides to use different pages for I/O all the time. The recent distributions have options in the to prevent that from happening.
---------------------------------------------------------------------- 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
