 |
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.
|
|
|
|
|
