Tight Memory Kludge in USG 3B2 5.3

[campbell at sauron.UUCP]

In article <141 at opusys.UUCP> jk at opusys.UUCP (John Kullmann) writes:
>Since switching from 5.2.2 to 5.3 we've noticed frequent
>console messages like:
>  ptalloc - Insufficient memory to allocate %d pages - system call failed
>
>Where 5.2.2 would sleep at various places along the fork() path,
>5.3 has all this NOSLEEP nonsense, returns EAGAIN(!!) and fails. 
>Basically, if you do not have enough free memory to dup all the private
>regions of your process (see procdup()/dupreg()) under 5.3 you are out of luck. 
>This is a major change from 5.2 and one that doesn't seem beneficial.
>
>Anyone else running into this? Anyone understand this? Anyone
>justify this? Anyone have a fix for this??
>
>John Kullmann
>opus systems
>..!{sun,pyramid,hplabs}!opusys!jk

The reason that the code was changed (at least from VAX V.2.2 to 3B2 V.3) was
to allow the general user memory pool to be used to allocate the "r_list" of
regions and the PDE and DBD maps.  It's justifiable given that "sptmap" no
longer must be as large, thus freeing more memory to the general pool.

I don't have a 3B2 on which to try any fix, but looking at the code I'd try
asserting "dupreg()" with the second parameter set to 0, i.e., SLEEP.  I'd
then modify the "ptalloc()" code to pay attention to the flag...right now
it seems to igmore what you tell it.  Let me warn you though that this is
just a first approximation...I have not looked into this that deeply.  When
you do this you are going to get notification messages on your console telling
you that "getcpages()" is sleeping waiting for a page.  The fact that the
developers hardwired "NOSLEEP" into "ptalloc()" probably means that there is
some problem with this approach, however.

The best solution would be adding more physical memory to the box.  Getting
this message means that general memory is EXTREMELY tight...you don't have
the couple of pages necessary to do your memory management upkeep.  Another
solution would be to play with your memory configuration parameters and
tune them so that paging would begin sooner.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell