jk@opusys.UUCP (John Kullmann) (09/05/86)
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!jkcampbell@sauron.UUCP (09/10/86)
In article <141@opusys.UUCP> jk@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