  Setting Global Pages? (GBLPAGES) 
 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.
 
 Answer written or last revised on  10-JUL-2002 
