Shane wrote: > On Tue, 2010-08-17 at 13:27 -0500, Elpida Tzortzatos. wrote: > > > 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. > > Much as I am a long time MVS bigot, it would be remiss not to point out > that Linux supports various sized "large" pages across disparate > architectures - none of them smaller than 1 Meg I would think.
Different processor architectures support a variety of pages sizes. For example, Itanium or whatever it is called today has architected page sizes of 4K, 8K, 16K, 64K, 256K, 1M, 4M, 16M, 64M, 256M, and 4G. Power supports 4K, 64K, and larger implementation defined sizes such as 16M and 16G. I can > > Not to mention multiple (concurrent) sizes within particular > architectures. I considered z/OS "late to the party" when this was > announced. Although Linux supports multiple sizes of larger pages, as a practical matter using more than one is cumbersome, and I not sure what, if any, application does. Pools of each size have to be preallocated. In Linux page tables are not sharable, so applications with large shared memory segments with a lot of processes attached to them, such as some relational data bases, can chew up a lot of real memory with page tables to map the shared segments. > Welcome, but late. > And if you want to utilise this as a z/VM guest ??? - too bad. All the > software and hardware is IBM proprietary - how is that acceptable ? > > > 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. > > I have to question this ambivalent attitude. If TLB hit ratio is such a > major consideration, how can the possibility of allocation on a > "foreign" book be even contemplated as acceptable ?. > Even the current processors have shown susceptibility to performance > impacts due to poor CP allocation at LPAR activation - are you prepared > to accept that memory allocation won't be similarly impacted by poor > decisions ?. > > Shane ... > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html Henry ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
