On Tue, 17 Aug 2010 20:19:04 +1000, Shane <[email protected]> wrote:
>I have been following this thread as an interested spectator, not having >had the opportunity to "play". Even zLinux has had large pages for a >while now - pity about z/VM ... ahem. >Linux doesn't attempt to break up large pages under memory pressure, but >does allow the number of such pages to be dynamically adjusted (I >haven't checked the zLinux code, but I presume it does likewise). It >also spreads the allocation across any (NUMA) memory nodes that are >available - does zSeries do likewise across multiple books ?. > >Shane ... You are correct Linux and zLinux do not allow for break up of large pages under memory pressure. zLinux will not use the 1MB memory pool when the 4K memory pool is memory over committed. In this case the 4K memory pool will page even when there are plenty of 1MB frames available in the 1MB pool. z/OS is more flexible in this case in that it will use available frames from the 1MB pool before paging the 4K pool. zLinux does have options that allow the user to decrease/increase the size of the 1MB memory pool after the initial IPL specification. However it needs to be noted that if the 1MB frames are allocated this decrease will not take affect until the allocated virtual storage is freed by the application. For z/OS this would not have much value when DB2 has most of the 1MB pages allocated for its use unless we developed an interface with the middleware where z/OS can ask for these frames to be released. With APAR OA31116 (base z/OS 1.12) z/OS can transparently decrease the size of the 1MB memory pool dynamically based on the current workload demands of the system so long as there are some unallocated 1MB frames. Support to increase the size of the 1MB memory pool after IPL would be very complicated since it would need to deal with memory fragmentation issues and the ability to relocate pages and deal with pinned pages in order to satisfy the contiguity requirements of the 1MB architecture. The process to increase the size of the 1MB memory pool after IPL tends to be costly. The goal of every platform is to move to transparent use of large pages but that is a very high goal to achieve especially when the large page size is 1MB (256 contiguous 4k Frames). Implementation of large pages is much simpler and more flexible with smaller large page sizes but the complexity increases with larger large pages sizes. Given the performance results we have seen from the exploitation of large pages by DB2 and JAVA, z/OS is investing a lot in making this technology more flexible in the future. For now, exploiting large pages in z/OS takes some capacity planning on your part (as it does in other platforms). I am glad you mentioned zLinux since as you can see the z/OS implementation is more flexible in some aspects especially given the 1MB large page size. When it comes to memory topology, our hypervisor (PR/SM) is aware but z/OS itself is agnostic as to hardware memory topology. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
