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