*BSD News Article 27855


Return to BSD News archive

Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!news.ans.net!dennis
From: dennis@ans.net (Dennis Ferguson)
Subject: Re: Notes on the *new* FreeBSD V1.1 VM system
Sender: news@ans.net (News Administrator)
Message-ID: <1994Mar1.132637.58107@ans.net>
Date: Tue, 1 Mar 1994 13:26:37 GMT
References: <CLutBp.4K9@flatlin.ka.sub.org> <RA0Jn4G.dysonj@delphi.com> <2kudpoINNbhd@CS.UTK.EDU>
Organization: hardly any
Lines: 43

In article <2kudpoINNbhd@CS.UTK.EDU> moore@cs.utk.edu writes:
>In article <RA0Jn4G.dysonj@delphi.com>, John Dyson <dysonj@delphi.com> writes:
>> Christoph Badura <bad@flatlin.ka.sub.org> writes:
>>  
>> >Getting it right means, not overcommiting VM and not killing random
>> >processes.
>
>Damn straight.  Let's not have FreeBSD go the way of AIX.
>
>I don't think this is that hard...all you need is a count of the
>number of unallocated pages of swap space.  When someone allocates
>more pages, you decrement the count; if there's not enough room, fail.
>When pages are freed, you add them back to the available page count.
>The performance impact is minimal except perhaps on multiprocessor
>systems where you have to get exclusive access to the counter.

I don't think it is quite so easy, or clear.  Pages are explicitly
allocated by sbrk(), but are also implicitly and tentatively allocated
by fork().  If a 60 Mb process wants to fork() so it can execve() a small
shell command, do you really want to have to configure an extra 60 Mb
or more of swap space to allow this, or make the fork() fail if the
backing store for the entire extra 60 Mb isn't available?  With
copy-on-write fork()s a fork()-exec() is extremely likely to actually
use nearly none of that allocation, and I think you get a more useable
system if you don't demand that it be there.

I hence wouldn't be quite so religious about not over-committing,
and might prefer to play the probabilities a bit.  Memory obtained
from sbrk(), or by execve(), will probably be used and hence should
probably find backing store to back it up.  Memory tentatively
obtained via fork(), however, probably won't be used since most
fork()'s are followed fairly closely by an execve(), so it is
probably less useful to require that backing store for this be
found ahead of time.  This does leave you exposed to the possibility
that a 60 Mb process will fork() but not execve(), and that the
swap space will be subsequently eaten up by having one of the pair
of processes write all its pages, in which case something which
doesn't expect to die will have to anyway.  This should be a much
rarer occurance, however, and the benefits of being able to
fork()-execve() something small no matter how big the parent process
has grown probably justify the risk.

Dennis Ferguson