Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!jarthur!uunet!contex!james
From: james@contex.UUCP (James McQueston)
Newsgroups: comp.sys.sgi
Subject: Re: Swap questions
Summary: behavior in 3.3 not desirable to some of us.
Message-ID: <1539@contex.UUCP>
Date: 30 Nov 90 22:38:32 GMT
References: <9011150232.AA00704@koko.pdi.com> <1990Nov28.163415.14317@odin.corp.sgi.com>
Organization: Xyvision Design Systems, Wakefield MA
Lines: 37

In article <1990Nov28.163415.14317@odin.corp.sgi.com>, jmb@patton.wpd.sgi.com (Doctor Software) writes:
> ................... your total virtual memory is (real memory) + (swap
> memory). If swap is too small, and a process has pages which need to be
> swapped, the OS kills the process in order to avoid deadlock. This only
> happens in the case that memory is filled, the OS needs to page
> something out to keep going, and there are no pages of swap left free.
> 
> This seems to make the lesson be that you can run quite fine without
> swap until you actually need to use it - but then watch out. There's no
> garuntee of which process will actually be killed in this case, its 
> just whomever has the page that can't go out.
> ...
> -- Jim Barton
>    Silicon Graphics Computer Systems
>    jmb@sgi.com

This is what we thought, as it is mentioned in the "bug fixes" section of
the release notes for 3.3.  We tested it, and were upset that we could not
determine which process got killed when swap runs out.  We were so concerned
that we placed a call (CALL ID F1017) and I talked to Tom Mitchell about this
for quite some time.  It is very important that the users be able to determine
which process(es) get killed in order to solve the deadlock.

Example: your server is used to run a simulation that takes hours or days to
compute, and you have tuned the size of your finite-element mesh to just
barely fit within the capabilities of that machine.  N hours later, someone
else innocently runs some unimportant program on the server and causes page
deadlock.  The O.S. blindly decides which process to kill and ... pow!  Chance
determines that the simulation gets killed and you lose N hours of work.
Too bad that the other user was just checking his mail.

Suggestion: there should be some prioritization of the importance of processes
when determining which one(s) should be killed to avoid deadlock.  Perhaps
the processes priority or "nice" value could be used.  Anything is better
than nothing.  Users MUST have some way of guiding the OS in this decision.

--jhm (reply broken, use contex!james@uunet.uu.net or ...!uunet!contex!james)