Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.sys.att
Subject: Re: Sys V/386/3.2 UNIX system getting hung (?)
Summary: Swapping deadlock!
Keywords: 6386, UNIX, kernel, confused, swapping, deadlock
Message-ID: <821@aber-cs.UUCP>
Date: 14 Apr 89 22:27:36 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 55

In article <2379@maccs.McMaster.CA> nusip@maccs.UUCP (Mike Borza) writes:
    
    In article <228@cs-col.Columbia.NCR.COM> vause@cs-col.Columbia.NCR.COM (Sam Vause) writes:
    >In article <6226@homxc.ATT.COM> mrb1@homxc.ATT.COM (M.BAKER) writes:
    >>	We have an AT&T 6386E system running UNIX SysV/3.2.
    >>	While running our application, it has been observed to
    >>	'hang'.  Specifically, the application stops in the
    >>       [more info about hangs deleted...]
    >
    This also concurs with my experience.  Our 386 with 4 MB of memory
    is used to develop X-Windows applications under ISC 386/ix (1.0.6).

Great!

    Based on analysis of sar output, we decided to increase, among
    other things, the number of disk buffes..

Always a nice idea!

    Under unpredictable circumstances, the system would slow to a crawl,
    sometimes dying and sometimes recovering without any intervention.  At
    other times, the system would just die, sometimes echoing characters
    typed at the console and serial terminals, sometimes not.

Happens to me as well... With Enix 5.3.2

    Reducing the amount of space allocated to some of the bigger kernel
    resources always restored reliable functionality for our application
    mix.

Indeed. The problem is swapper lockout. When work resumes, it is because
some 2-3 second swapper timeout has expired; when it stops for good, it is
because the dreaded swapper deadlock has happened (well documented in Bach's
book, page 195, if I remember well). Note that for it to happen, apparently,
swap space need not be full; the problem is with memory being tight.

Unix System 5.3.2 (aka 386ix 2.0) has two tunables at system geenration that
ought to be useful to prevent the phenomenon, high water marks for memory
and swap free, but to really work, they need to be set larger than the size
of the largest process that may cause the problem.

The System 5 swapper, as Bach says in not so many words, sucks. He also adds
that there is little interest in fixing it; just add more memory... Too bad
that the extra memory costs more than the UNIX licence.

    Prior to acquiring X, we were able to use substantially more disk
    buffers before encountering this problem.  Most interesting (and
    annoying).

QED. When there are several big processes, that tend to stay swapped,
the probability of problems rises a lot.
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk