|
HP OpenVMS Systemsask the wizard |
|
The Question is: What's up with autogen wanting over 100,000,000 gblpages? Running autogen from savparams to testfiles reports 158,000 globalpages used and wants to set gblpages to over 100,000,000. This started with the upgrade to VMS 7.3, version 7.1 did not exhibit thi s behavior. I have set max_gblpages to 500,000 and the system is runs fine. This is a cluster with 2 DS20s and a ES45 all with 4GB of memory. The Answer is : Please see topics (6536) and (5002), and see the following (edited slightly from another forum) response to this question: The setting of GBLPAGES determines the size of the Global Page Table (GPT), and it is now initially sized to support larger RMS caches and other (large) users of global pages. Now for some details on the cost of setting GBLPAGES, in terms of the new physical memory requirements: the cost of sizing the GPT is three memory pages (assuming an eight kilobyte page size) for every four million pages (well, actually, every 4,194,304 pages) configured in the system. In other words, the overhead of the new higher setting is viewed as very low, and the value derived from easily increasing the available global pages and particularly in easily increasing in the available RMS caching are viewed as reasonable trade-offs. As for how to memory cost of the GBLPAGES (GPT) setting was determined: on Alpha, the page table entries (PTEs) are 8 bytes in size and one is needed for page mapped. Assuming the current standard page size of eight kilobytes that is found on current Alpha systems, the page tables will need 1/1024 of the virtual address space that the tables will map. The GPT is mapped in S2 space virtual memory, and these tables are initially demand zero pages -- this means the tables require no physical memory until the GPT is referenced and the global pages are used. (This behaviour has been the case for a long time -- as the global pages are actually used, the pages comprising the GPT are instantiated and locked into memory.) Therefore, the physical memory consumption is solely for the system page tables that are required to map the global page table. This yields another reduction in memory requirements of a factor of 1024. If global page table space for three-quarters of the total physical memory is provided -- as is the case on V7.3 and later -- the initial (large) setting of GBLPAGES consumes three pages for every 4,194,304 (4*1024*1024) pages of the of the available system physical memory. In other words, setting up the GPT large is cheap -- and you then pay for what global pages you actually use, as you always have. But you don't have to manage and you don't have to resize the GPT unless you want to. If the new GPT sizing bothers you, you can revert to the older setting and/or you can buy more memory -- OpenVMS Engineering believes that this change was a good (and a cheap) trade-off for the benefits that it provides.
|