Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!hookup!swrinde!gatech!europa.eng.gtefsd.com!news.msfc.nasa.gov!cs.utk.edu!cs.utk.edu!moore From: moore@cs.utk.edu (Keith Moore) Newsgroups: comp.os.386bsd.development Subject: Re: Notes on the *new* FreeBSD V1.1 VM system Date: 2 Mar 1994 07:57:29 GMT Organization: Univ. of Tenn. Computer Science, Knoxville Lines: 66 Distribution: world Message-ID: <2l1gt9INNc23@CS.UTK.EDU> References: <CLutBp.4K9@flatlin.ka.sub.org> <RA0Jn4G.dysonj@delphi.com> <2kudpoINNbhd@CS.UTK.EDU> <1994Mar1.132637.58107@ans.net> Reply-To: moore@cs.utk.edu NNTP-Posting-Host: wilma.cs.utk.edu In article <1994Mar1.132637.58107@ans.net>, dennis@ans.net (Dennis Ferguson) writes: > In article <2kudpoINNbhd@CS.UTK.EDU> moore@cs.utk.edu writes: > > > >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? Gee, I'd rather have vfork() stay around than break the way memory allocation works with sbrk/fork. > 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. Depends on what you mean by usable. If you don't generate a failure when someone asks for memory, then some random app gets nuked -- in my experience, it's often something that's important. Programs that really need to be robust in such an environment have to go throught all kinds of special pains to keep on working -- like touching every page after they malloc it, or trapping SIGDANGER on AIX, or whatever. I consider *that* unusable. > 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. Statistically speaking, you're probably right, but I'd still want this to be optional behavior. Also, if a process forks but the child doesn't exec, I'd want that child to be the one to be nuked when it asked for space, instead of the child getting the space and some other process getting nuked on a page fault. And I'd certainly want the exec call to actually reserve the swap pages. BTW, None of this is nearly as bad as the usual reason I've heard for doing lazy allocation -- allowing people to use huge or sparse FORTRAN arrays without actually needing that much swap space. (good way to kill your automounter!) -- Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx Preserve the fourth amendment! Say HELL NO to key escrow!