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