*BSD News Article 27820


Return to BSD News archive

Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna.cs.rmit.oz.au!aggedor.rmit.EDU.AU!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!cs.utexas.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!nigel.msen.com!math.fu-berlin.de!news.th-darmstadt.de!zib-berlin.de!easix!flyer.GUN.de!flatlin!bad
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Date: Sat, 26 Feb 1994 23:02:12 GMT
Message-ID: <CLutBp.4K9@flatlin.ka.sub.org>
References: <BcxpGux.dysonj@delphi.com> <2ke3ss$l0d@u.cc.utah.edu> <Ja4p+zR.dysonj@delphi.com> <2kfcur$dd1@germany.eu.net> <2kgdcd$mls@usenet.pa.dec.com> <2kkqib$h2h@Germany.EU.net>
Organization: Guru Systems/Funware Department
Lines: 23

In <2kkqib$h2h@Germany.EU.net> bs@Germany.EU.net (Bernard Steiner) writes:
>In article <2kgdcd$mls@usenet.pa.dec.com>, paik@mlo.dec.com (Samuel S. Paik) writes:
>|> Please go read the deadlock literature.  There are basically four "solution
>|> strategies" to deadlock: prevention by allowing resources to be allocated
>|> only in certain patterns; avoidance by refusing to allocate resources when
>|> you may end up with a deadlock; detection when it occurs and killing to
>|> break the deadlock; and stick head in the mud (unix).  

>Since you have no a-prioro knowledge of a processes behaviour wrt memory
>consumtion, the first two solutions are unviable.

Since a couple of Unix versions get this right, like say SVR3, SVR3,
and 4.3BSD, you're proven wrong.

Getting it right means, not overcommiting VM and not killing random
processes.  The cited versions simply fail the system call that
requests more VM when no more is available.

-- 
Christoph Badura	bad@flatlin.ka.sub.org		+49 721 606137

Es genuegt nicht, keine Gedanken zu haben;
man muss auch unfaehig sein, sie auszudruecken.  - Karl Kraus