swap space

[Kevin Darcy]

In article <1991Jun13.192444.7500 at ucunix.san.uc.edu> adams at ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes:
>In article <1991Jun13.122803.25362 at ims.alaska.edu> floyd at ims.alaska.edu
>(Floyd Davidson) writes:
>>[...]
>>In article <1991Jun13.065207.10089 at ucunix.san.uc.edu>
>>adams at ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes: 
>
>System V rel. 2.1 and later and 4.1BSD and later adopted different
>philosophies regarding the implementation of demand-paged virtual
>memory.  The BSD systems, being research-oriented and likely to be used
>by programmers with a more intimate knowledge of the inner workings of
>the O/S, chose simple, less elegant approaches to memory management with
>provisions, such as the vfork() call, for the programmer to tune the
>system to the application.  In 4.xBSD, swap space is allocated at the
>birth of a process, with enough space being allocated to contain the
>entire virtual image of the process in its initial state
>(text+data+BSS), excepting of course malloc'd (heap) space obtained
>via sbrk() or stack space pushdown expansion, and the user structure and
>page tables which are RAM-resident for an active (non-swapped) process.
>
>System V took the approach of being as elegant as possible (e.g., using
>copy-on-write and dynamic allocation of all tables except the actual
>physical memory map) and hiding the inner workings of the system from
>programmer intervention.  In the System V scheme, swap space is
>allocated as needed by the page stealer to swap out pages or processes
>as needed.  Thus, allocation of swap space is not made until it is
>actually used.  Since process sharable text and data may be
>demand-paged in from the filesystem, virtual pages may be mapped to one
>of three places: physical RAM, swap space, or the executable program
>file.

Although I'm no kernel hacker, I will point out, from a sysadmin's point-of-
view (with advice from the higher levels of AT&T support/development people)
that later SysV implementations still retain vestiges of the old virtual 
memory scheme you describe: on an AT&T 3B2/600 running r3, for instance, the 
kernel always attempts to map two -entire- sets of -contiguous- pages in the 
swap area for every process upon startup, whenever sbrk() is called for more 
memory, and so on. One of these sets is for paging, and the other, for 
swapping. If, for some reason, there is not enough contiguous space available 
to allocate one of these sets, the kernel spits out a "getcpages: cannot 
allocate X contiguous pages" console message (X being some-number-or-other). 
If there is insufficient contiguous space to map EITHER page, new processes 
will die on startup, or ungrowable processes will (usually) seg violate, with 
all of this mayhem accompanied by delightful kernel messages such as "growreg: 
unable to allocate ...", or "dupreg: unable to allocate..." or "uballoc: 
<something-or-other>" spewing on the console.

The algorithm for mapping this swap space is unknown to me, but it appears to 
be imperfect - from time to time, one of our 3B2's or another will suddenly 
experience these symptoms for no particular reason, and plenty of available 
swap space. Once it starts, even programs with relatively small run-time 
images (e.g. /bin/cat) will then die on startup, with the kernel complaining 
that it cannot allocate swap-area space. Obviously, the only cure at that 
point is to reboot...

Perhaps AT&T has been slow in -implementing- the VM "elegance" of which you 
speak? I see very little of it on their own products.

>-- 
>       Jim Adams              Department of Physiology and Biophysics
>adams at ucunix.san.uc.edu     University of Cincinnati College of Medicine      
>      "I like the symbol visually, plus it will confuse people." 
>                                       ... Jim Morrison

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