From: kevin@cfctech.cfc.com (Kevin Darcy)
Newsgroups: comp.sys.att,comp.unix.sys5.misc,comp.unix.misc
Subject: Re: 3B2 feeling ill(Please HELP)!!
Date: 6 Oct 92 00:47:36 GMT
Organization: Chrysler Financial Corp., Southfield, MI

In article <1ai0ksINNh7t@uwm.edu> adk@csd4.csd.uwm.edu (Andrew D Kailhofer) writes:
>In article <443@bdofed.UUCP> bob@bdofed.UUCP (n) writes:
>>
>>HELP!!!
>>
>>I have two 3B2 computers, 700 and 622, that have started to feel ill.
>>
>>The 700 is worse than the 622 right now. I get the following message
>>comming up.
>>
>>NOTICE: dupreg - Insufficient memory to allocate 1 page - system call failed
>>...  and so on ...
>>NOTICE: exece - Insufficient memory to allocate 8 pages - system call failed
>>
>> ...
>>
>>Specs:		AT&T 3B2/700
>>		28 MB ram
>		^^^^^^^^^  pretty biggish (for a 3B)!!!

We have dozens of 3B2's with this much memory. But you have to be a model 622
or higher in order to use the 16Mb cards. I hear the Navy has some 64Mb 3B2's,
and at one point, AT&T was considering coming out with 64Mb boards, so you
could conceivably cram 256Mb into a single machine...

>>		1.2Gb disk	( 4-300Mb)
>>		41??? block of swap.
>		^^^^^ This is at most 21MB-1 !!!
>>
>>Applications:	90% WP5.0/4.2
>>		10% oracle/2020
>>
>
>I had this problem on a 3B2/600 with only 12 MB of RAM, and I make it
>go away by increasing the size of my swap space.  If you have 26K
>blocks of swap free, it's not likely that that is the problem, unless
>your executables soak up 13MB when they do their thing.
>
>I'm pretty sure that when I looked in the source that this was caused
>by insufficient swap, rather than insufficient physical memory.  I
>just looked in the source (if you have a SVR3.2.* source license look
>in the file /usr/src/uts/3b2/os/region.c) and it will also offer this
>message if it can't allocate more memory w/o causing potential
>deadlock.
>
>The only kicker here is that you have only 21MB of swap space, at
>most.  I would have used more.

As it was explained to us, whenever a process forks on a 3B2, the kernel 
pre-allocates the appropriate amount of swap space for paging the process 
*AND* the same amount of swap space for swapping the process out completely. 
This seems wasteful to me, but is probably easier to implement for the kernel 
programmers (since the paging and the swapping code are somewhat distinct
from each other). BOTH of these chunks of space need to be contiguous, so if 
your swap space allocations get all fragmented, you might run into these sorts 
of problems, even if your total space usage is OK. Rebooting regularly helps 
avoid such fragmentation. The upshot of all this is that to be absolutely 
safe, you need to allocate roughly DOUBLE the amount of your physical memory 
to swap space on a 3B2. 

When the kernel can't allocate one of these contiguous images, it issues a 
"getcpages: can't allocate XX pages of contiguous memory" warning, which may 
be seen in your console log. This is the first sign of trouble. If the kernel 
can't allocate EITHER image, the fork will fail completely. Under some rare 
obscure set of circumstances, the kernel will then lose its mind, and decide 
that ALL future allocation requests fail. That's when you get system 
malfunction, with the pages and pages of dupreg/growreg/uballoc/exece error 
messages such as the above, and the only solution I know is to reboot at that 
point.

>I would add some (5MB? 10MB? 602MB?) swap space (w/ swap -a) and see
>if the frequency of these messages decreases.  Remember that (assuming
>you have a spare disk partition) you can add (and delete!) swap space
>on the fly under SVR>=3.

Well, technically, you can't delete an ACTIVE swap partition: in theory, 
swap -d marks the partition as being "in the process of deletion", excuses it
from all new swap space allocations, and then eventually deletes only when it 
becomes totally inactive. I imagine this could be troublesome on extremely 
busy systems, but I've never personally witnessed an "in the process of 
deletion" swap partition yet. Then again, I don't go deleting them very often, 
either... :-)

------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		  | Kevin Darcy, Unix Systems Administrator
...destroyer!cfctech!kevin 	  | Technical Services (CFC)
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence Ave, Center Line, MI 48015
------------------------------------------------------------------------------
Newsgroups: comp.sys.att