Sys V handling of insufficient swap space.

[greg at osiris.UUCP]

There seems to be a bit of confusion with regard to this.  Firstly, to the
best of my knowledge all System V.2 implementations will hang when they run out
of swap space.  A rough description of how this occurs follows....

    The scheduler runs
	It looks around and possibly finds a process to run
	It then checks the amount of free memory and decides that it must
	swap a process out - calls swapout()
	    swapout() picks a process to swap and starts copying it to swap
	    but discovers that there is not enough swap space so it sleeps
	    until more appears.

Now if you're lucky the process picked to run may free up enough swap space
to allow swapout() to continue and everythings fine until the next
call to swapout().  However, if it doesn't free up enough space your system
is now officially hung since the scheduler is asleep in swapout() and no
longer doing its job.  Which means that no more processes are scheduled
and the whole system goes idle, regardless of how many runnable processes
there are or how much physical memory is available.

This is a major problem on any machine used for software development since any
program which starts infinite recursion will eventually run out of swap space.
For example the one line program
	main(){main();}
will cause the system to hang.

Allocating more swap space won't solve the problem a unless you have at least
enough swap to hold the biggest possible program (say 2 Gigabytes for a machine
with a reasonable sized virtual address space).  Though this is probably
feasable, I don't want to waste that much disc space just on the off chance
that somebody might make a mistake.

The only real solution is to change the kernel so that you are guaranteed to
get more swap space and this can only really be done by killing processes.
We have made the necessary mods to the kernel we sell with our hardware and
it is virtually impossible to cause this problem on our machines.  For various
complex reasons you can't always kill a process, so our kernel can be made
to hang but it requires deliberate programming effort and special circumstances.
-- 

Greg Kable
Osiris Technology Pty. Ltd.	    ACSnet:  greg at osiris.oz
Unit 4				      UUCP:  ...!seismo!munnari!osiris.oz!greg
372 Eastern Valley Way		      ARPA:  greg%osiris.oz at seismo.arpa
Chatswood, NSW	2067		     VOICE:  (02) 406 6299
Australia