|
HP OpenVMS Systemsask the wizard |
|
The Question is: I recently saw in a SYSTARTUP_VMS.COM (on a SEPS Y2K system) a check to see if CTLPAGES-CTLIMGLIM was >= 128. If so a mail was sent to SYSTEM saying the system parameters should be changed. What is the significance of this check? The Answer is :
There are certain obscure circumstances where some DECnet-Plus processes
can grow until their virtual address space is exhausted, and maintaining
the delta between CTLPAGES and CTLIMGLIM to a value of 128 or less (on
OpenVMS VAX) has been shown to reduce or eliminate the incidence.
This error is remedied by the VAXSYS08_062 and later ECO kits for V6.2.
This problem is known to arise in V6.1 and V6.2. SEPS (DECstep) appears
to erroneously still include the check on V7.1, though the problem does
not appear to arise on the OpenVMS version in question -- the OpenVMS
Wizard will pass this along to the DECstep team.
For anyone who has nothing better to do than wonder about the magic value
of 128 pages, here is a brief explanation:
1. CTLPAGES is an area of P1 space which may be used for both process
specific and image specific allocations. If there is insufficient
free space in CTLPAGES then a 'process' allocation will fail,
whereas an 'image' allocation will 'overflow' into P0 space and
allocate some of that.
P0 space is deleted when an image exits, so if the allocation is
only required for the life of the image then it can be satisfied
from P0 space, otherwise it MUST be satisfied from P1 space, which
survives until process deletion.
2. CTLIMGLIM is a limit on the amount of P1 space that can be
allocated for image purposes --- In other words, image allocations
are forced to use P0 space before all of CTLPAGES is consumed, and
thus this reserves some P1 for process allocations.
3. The allocation algorithm for image allocations is as follows:
a. Try to allocate some P1 space, and if this fails then allocate
P0 space. On failure, skip to '3d'.
b. If allocation of P1 space is successful then if the total
image allocation is below CTLIMGLIM then all is OK.
c. Else (Oooops), too much P1 space was allocated, so deallocate
the block and go to '3d'.
d. Allocate memory from P0 space, returning a success or failure
status to the caller.
e. Caller uses memory and then deallocates it (returning it to
the free list).
4. The bug occured at step '3c'. If the block being deallocated was
adjacent to any other free blocks of P1 space then the deallocation
routine would amalgamate (merge) the adjacent free blocks and would
return the total size of the large, amalgamated free block. This in
effect 'corrupts' the request size so that it was no longer the
original request size, but an arbitrarily larger size. This is
only a minor problem, unless the amalgamated block is greater than
64 kilobytes (ie it is only a problem if it takes more than a word
to store the length of the block). The problem only shows up if the
amalgamated block is greater than 64 kilobytes, which means that
it only shows up if there is at least 64 kilobytes of free CTLPAGES
in P1 space. Even when there is more than 64 kilobytes free, the
problem might not show up, as it all depends upon the level of
fragmentation of the CTLPAGES pool. Therefore, the problem may
appear to come and go in an unpredictable way.
5. 64 kilobytes is equivilent to 128 pages on OpenVMS VAX. Therefore,
as image allocations will succeed until CTLIMGLIM is reached, the
implication is that the 'fail-over' into P0 space will only occur
when CTLIMGLIM pages have already been allocated, and therefore
when the amount of free P1 is less than CTLPAGES minus CTLIMGLIM.
6. The DNS Clerk (SYS$NAME_SERVICES) allocates unusually large chunks
of CTLPAGES. Certainly these chunks can be in excess of 16 kilobyte
bytes, but probably not much larger. (The uncertainty about the
maximum size is the reason that the OpenVMS Wizard cannot specify
a precise relationship between CTLPAGES and CTLIMGLIM.) Take an
example where the image allocation is currently 16 kilobytes (32
pages) below CTLIMGLIM, so image allocations of 16k will succeed.
If an allocation request is made for 16 kilobytes plus 1 byte,
then it will fail. If all the free memory in P1 is adjacent then
the size of the free block could be as large as CTLPAGES minus
CTLIMGLIM *plus* the 32 pages of CTLIMGLIM which has not yet been
consumed. Thus:
Potential problem if 128 < 32 + CTLPAGES - CTLIMGLIM
Potential problem if 96 < CTLPAGES - CTLIMGLIM
7. There is a substantial element of uncertainty in the above figures.
Specifically, the maximum DNS allocation is not defined (somewhere
greater than 16 kilobytes) and some of the 'process' part of
CTLPAGES will *always* have been consumed (for example, by process
logical names and the channel table).
|